Because the rich text element ships with browser default styling, not yours. You designed beautiful headings and generous spacing on the page, then the CMS content renders as cramped Times New Roman with no rhythm. The element is doing exactly what it was told. Nobody has told it anything yet.
This is the single most common gap we find when we audit a Webflow site somebody else built. The homepage is polished. The blog looks like a 2005 forum post. It happens because rich text styling is the one part of a Webflow build that does not get styled by clicking on the thing you can see.
The fix is not difficult, but it is different from the rest of the Designer, and it has one trap that catches people. This is how we set it up, in the order we do it, and what we do about the parts Webflow does not handle for you.
It is a single element that holds formatted content produced by an editor rather than by a designer. Webflow's own glossary describes a rich text field as an input field for formatting or applying text styles such as bold, colors, font sizes, italics and underline, and notes that rich text fields also support links, images, inline media and lists.
The important part is where the content comes from. Everything inside a rich text block arrives from the CMS or from someone typing in the Editor. You do not place those headings and paragraphs by hand, so you cannot select and style them the way you style the rest of a page.
That is why it behaves differently. A rich text block is a container whose children are generated at publish time. Your job is to define what those children should look like before they exist, which is closer to writing a stylesheet than to designing a layout.
Two ways, and you will use both. You can style the underlying HTML tags globally, which sets a site-wide default for every heading and paragraph. Or you can style tags nested inside a class, which limits the styling to rich text blocks carrying that class. The second option is the one that keeps your site sane.
Webflow itself describes both approaches. In its update announcing improvements to rich text elements, Webflow notes that previously, styling individual elements within a rich text block required inheriting styles from HTML tags or using a nested selector inside of a class. Those two routes are still the foundation, and understanding them is what stops rich text styling from feeling like guesswork.
Our practice is to give the rich text element a dedicated class before touching a single style. Not a generic layout class it shares with other containers, a class that exists only for rich text. Everything after that hangs off that decision, and skipping it is the root cause of most rich text problems we get called in to fix.
Webflow made the inside of the block directly editable. In its update Improvements to rich text elements, launched on November 2, 2023, Webflow states that you can now style individual elements within a rich text block directly from the Style panel and enjoy more granular design control, rather than only through tags or nested selectors.
The same update improved two other things worth knowing. Webflow says you can rearrange or delete rich text elements directly from the Navigator by clicking and dragging or through keyboard shortcuts, and that all individual elements are now displayed in the Navigator. That makes the structure visible instead of hidden inside a single block.
Webflow also added conditional visibility, stating that you can set conditional visibility for each element directly from the Settings panel so you can show or hide content as it makes sense for your audience, with no custom code required. That is genuinely useful for things like an optional callout that only appears on certain posts.
By scoping every nested style to a class that only rich text uses. This is the trap. A nested style applies to matching tags inside anything carrying that class, not only inside rich text blocks. If your rich text shares a class with other containers, your heading styles quietly follow that class everywhere it appears.
We have cleaned up sites where a designer styled headings inside a shared wrapper class and then spent days confused about why the pricing page headings kept changing. Nothing was broken. The style was doing what it was told, in more places than intended.
So the rule we hold to is one class, one purpose. Give the rich text element a class used for nothing else, and if you need a variation, use a combo class rather than reaching for the shared wrapper. This is the same discipline that naming systems enforce, which is one reason we lean on structured naming conventions like Client-First on larger builds.
Build the rich text style once, on a page you control, then reuse the class everywhere. Style every tag your writers actually use, then never style rich text again on a per-page basis. The whole point is that the next hundred posts inherit the work you did on the first one.
Start with the tags in order of frequency. Paragraphs first, because they carry most of the reading. Then the heading levels your writers use, usually two and three. Then links, then bold and italic, then blockquotes, then images, then lists. Work down that order and you will have covered nearly all real content before you get bored.
Spacing is where most people stop too early. It is not enough to style a heading. You have to style the space between a paragraph and the heading that follows it, which is different from the space between two paragraphs. Get those two relationships right and the content develops a rhythm that makes long posts readable. This is exactly the kind of thing worth capturing on a style guide page so it survives the next person who touches the site.
Style them as part of the rich text class, and set sensible defaults rather than hoping writers get it right. Images inside rich text need a maximum width, a border radius if your brand uses one, and vertical spacing. Blockquotes need enough visual difference to read as a quote without shouting.
Images are the ones that cause real damage if you ignore them. An unstyled image inside a rich text block will render at whatever size it was uploaded, which means one careless upload can break the layout and hurt your layout stability score. Setting a maximum width of one hundred percent and a sensible display behaviour on rich text images takes thirty seconds and prevents a whole category of problem.
Embeds are the awkward case, because you are styling something you do not control. A video embed or a third party widget brings its own markup. The most reliable approach we use is to give embedded content a wrapper with a fixed aspect ratio so the space is reserved before the embed loads, which stops the page jumping as the reader scrolls.
Both usually need a custom code embed. Webflow's glossary lists links, images, inline media such as videos, and lists among what rich text fields support. Tables and syntax-highlighted code blocks are not on that list, so plan for the embed and its styling up front rather than discovering the gap mid-launch.
Tables are the more common need, and they are worth doing properly because they break badly on phones. A table that looks fine on a laptop becomes an unreadable squeeze on a small screen unless you give it horizontal scrolling inside its own container. That single decision is the difference between a usable comparison table and one people give up on.
Code blocks matter if you publish anything technical. Without styling they render as an indistinguishable run of monospaced text with no background. A background colour, some padding, and horizontal scrolling make them legible. Both cases are a reminder that rich text covers most of what people write, and the rest is a deliberate build decision.
Write a torture-test post and publish it as a draft. Put every element you support into one article: all heading levels, a long paragraph, a short one, a link mid-sentence, bold and italic together, a blockquote, an image, a list, and an embed. Then look at it on a phone.
This takes twenty minutes and it catches almost everything. The problems that surface are always the same ones: two headings in a row with no space between them, a link that is invisible against the paragraph colour, a list with the wrong indent, an image that overflows. All easy to fix, all embarrassing to discover in a live post.
Do the check again after any theme or typography change. Rich text is downstream of your base type styles, so a change to your body font size can quietly break the spacing rhythm you set months earlier. We treat this as part of the launch checklist on every CMS build, alongside the wider blog CMS setup decisions.
Open your blog post template and check whether the rich text element has a class of its own. If it does not, give it one and rebuild your styles on top of it. If it shares a class with a general wrapper, that is the source of your problems.
Then write the torture-test post. Almost every rich text problem we have ever fixed would have been caught by that one article, and it costs less than half an hour. It is the cheapest quality check available on a CMS build.
If your blog looks off and you cannot work out why, we are happy to take a look. Send us a link to a post and we will tell you what we would change and roughly what it would take. You can find us at phoenix.studio, and we usually reply within 48 hours.
Tell us where you want to go. We'll tell you how we'd get you there.