CSS Grids Exported Code

I’ve been having a-lot of fun playing around with the grids and have just exported my first site which makes use of them over flex box, however looking into the code the grids have been assigned an ID with a computer generated name in a string of numbers, is there any way to rename this before exporting?

It feels messy and means when I’m bolting on my content management system of choice it makes things slightly confusing, not to mention making it near impossible to easily edit the nodes in the CSS without painstaking matching the names.

Also can someone clear up what these classes do? Am I correct in thinking they assign where content appears in a grid on smaller screen sizes?

Howdy Qwen! Grid developer here – I’ll try to answer your (great!) questions in detail:

the grids have been assigned an ID with a computer generated name in a string of numbers

This allows you to drag items around on the grid independent of each other, even if they use the same classes or duplicate IDs; in order to do this we need each child of a Grid to have a unique ID. We use this unique ID to control grid-item CSS independent of the CSS that you apply with your classes.

We care about the quality of our generated code, and I personally agree that these IDs are long and arbitrary. We made a compromise here to ship Grid to our users sooner, but we have some ideas for how we can improve the exported code:

One way we may try to improve this would be to use a similar auto-naming technique we use for auto-generated class names: For example, if you’re adding a Button to a grid, it might get an ID like button-1, button-3, etc.

A second, simpler improvement: we could use a simple counter to provide more concise and human-readable names, such as item-1, item-3, item-42, etc.

What do you think about these ideas? Would this help?

is there any way to rename [grid item IDs] before exporting?

Unfortunately this isn’t feasible at the moment; we could harness existing user-supplied IDs, but since it’s possible for users to provide duplicate IDs we decided against it, as it would lead to hard-to-track bugs.

making it near impossible to easily edit the nodes in the CSS without painstaking matching the names

If you supply an ID for an element, it will use that ID and a w-node class in the CSS; this should help make it easier to find the appropriate CSS.

Thanks for your feedback; hope the explanation helps!

P.S. If you’re truly desperate to use more human-readable names, you could supply an ID manually for each grid item, then do a search-and-replace on the exported CSS to replace all #item-id.w-node-abcdef-1234 { ... } selectors with #item-id { ... }

Here’s a tool you can use to strip w-node classes from your CSS: RegExr: Learn, Build, & Test RegEx
Here’s a tool to strip w-node classes from your HTML: RegExr: Learn, Build, & Test RegEx

(:point_up:These could very well break your HTML/CSS, so use at your own risk!)

That said, I would recommend just keeping the generated names for now as you’re less likely to run into problems that way. Thanks!


I do think either of the options you mentioned to provide more recognisable names would be handy with the added benefit of making the code look as slick as the rest of what Webflow produces.

I doubt I’m really going to be playing around with these nodes very much after export, my concern would come more when passing the code off to someone else who might have to dig a tiny bit to work out whats going on, but in the grand scheme of things its not really a massive issue or that time consuming to rename.

In terms of naming them, I’d suggest each item have gridname-item-#, I realise they’re already inside the grid in the html file, but they’ll probably be separated in the CSS.

Thanks for clearing things up for me @louroboros, I appreciate the detail you’ve gone into.

1 Like

There is another issue with this approach: every time you edit the grid cell, Webflow will add a new ruleset with the same ID in it’s CSS file. With time this will lead to a bloated CSS file with lots of consecutive rulesets having the same grid-node-id. How can we get rid of those no longer needed rulesets? Cleaning up CSS rules?

1 Like

This is currently not the case on tests I conducted. Can you provide an example?

Still bloated (26. september 2020.) :blue_heart:

Same here. Still bloated. If I export my CSS from Webflow, I can relate 16 IDs to the HTML, and >300 are not related by the HTML… so there is something strange going on.


Is it even possible to build a site, without having these messy ID’s in the markup?
I mean you cannot use grid (lol?) and even interactions are attached to it.

Let’s say I avoid both, still any issues regarding this?
Why not attaching it to a seperate class which we can name ourselves?

Hundreds of unused ID’s, I am sure Google and of course our customers will love it.

1 Like

You could give each grid a manual ID. This works fine, but Webflow then ads the 32 character long identifier ID to the class attribute of that element. Small win as you have better control over the naming convention of your elements, but the generated source code still looks messy.


I have the same issue. I think it has to do with copying and then pasting the new grid. I get weird left over styles in the css like this:

.biz-page-section > #w-node-_974a4cf6-1744-544f-94e0-8246132bfa2a-11f9146a {
	-ms-grid-row: 1;
	-ms-grid-row-span: 3;
	-ms-grid-column: 11;
	-ms-grid-column-span: 13;

There is no grid item with this ID in .biz-page-section grid.

Honestly, to this day, I think the exported CSS mess isn’t worth the ability to rearrange items irrespective of their CSS classes.

I never rearrange items within the grid. I place them in the DOM in the order I want them to appear. Maybe I don’t understand fully, but it seems much easier to simply rearrange items in the hierarchy. Any breakpoint rules are applied to my css class anyway. Maybe I just don’t get it.

I basically like grids, alot. They are nice to use to create layouts. But I never use them because I hate the exported CSS code, alot. I end up doing the same thing with flexbox, even though that is more complicated sometimes, because at least the exported CSS is readable.

Basically, would it be possible to have a version of the grid that assumes you won’t move grid items around and can, therefore, export prettier, more simple code? From your description I don’t understand why this couldn’t be an option.

1 Like

This is a major flaw. The beauty of Grid is that it allows you to layout items from the parent level without having to define separate classes/ids for each child. Webflow promises to export clean code; this flies in the face of that.

1 Like

Has there been any update on this topic?

1 Like

Greetings @louroboros,

This is an old thread, I know, but I also noticed what @Qwen wrote about the export code on grids. I think that the idea is good in and of itself, but why not change the implementation so that you create new classes for these gridded elements instead? Classes that is hidden from users in the designer, but that show up on the exported code like I know you already do in other cases? Another reason this would be better is because id’s is not something that is awesome to have all around your code either, and especially not when using frameworks like vuejs and react.

Wouldn’t it be possible to change the implementation this way instead?


How come there is no update from the team for years, and also why is the dev so dismissive on not being able to re-producing the issue?
My css file get bloated by 4000 lines of repetitive #w-node css and there is no easy way to remedy it. it has been several years! Without fixing it, I will not use Grid any more, and I have to spend weeks trying to remove all grid (pink label properties) from my project

Like others are saying, this is a major flaw that contradicts the core value of what Webflow promises. Please prioritize fixing this. @callmevlad Vlad Magdalin

How to produce, find a project that uses Grid, make changes multiple times, and then export the code. Sample a few #w-node-___ ids from the exported css file and try to search them in html code, see if there is an element with that id. Every id should be accounted for in the html. It not the case with my project.

Without fixing the issue for real, at least for a starter, you can safely delete every rule from export that is set to (excluding rules under breakpoints)

-ms-grid-column: span 1;
  grid-column-start: span 1;
  -ms-grid-column-span: 1;
  grid-column-end: span 1;
  -ms-grid-row: span 1;
  grid-row-start: span 1;
  -ms-grid-row-span: 1;
  grid-row-end: span 1;

It is the default setting, so it made no difference setting it vs. not setting it. This code account for most of my repetitive code

@Wenting_Zhang - Your points are valid and I hope they are considered. I ran into this myself on more than a few occasions. Now I prefer to just roll my own grid code for exported projects. No bloat and easier to maintain for me since I am happy to code. However this is not a real option for most. The platform is really geared to WF hosted projects.

Your approach can avoid the bloated code issue, but it undermines one of the best thing about Webflow - the visual grid editor. Grid is visually complex and not straight-forward to hand-code. Webflow UI solved this problem. Which is very unfortunate.

Another great thing about webflow is the ability to have clean and lean css code because the style manager can remove unused styles — that is when I never use Grid. The grid bloated css problem is very un-Webflow like

I still haven’t figured out the rhyme or reason behind adding all the w-node ids. They are happening on flex objects and collection items… it is rampant. I can understand adding a custom ID if I was actually manipulating grid children, but I am not. I never touch the pink styles. So why create an extra ID on the object with a matching class that is just the default settings over and over again. 70% of the CSS is repetitive useless code.

1 Like


Any news on this issue? Webflow is an awesome tool to use also as a developer who needs to export the design, but the code needs to be clean.

Thanks :heart:

I today found this bug as well. No matter how many times you delete areas in grid, you still have them in those #w-nodes that you can’t remove or change. I was only able to hack my CSS with overrides everywhere with !important