CSS Live Preview
Write CSS on the left and an editable HTML structure; see the rendered effect on the right in real time.
After editing CSS or HTML, click "Render" to refresh the right side.
CSS live preview: how the iframe size and defaults skew your judgement
The two boxes have separate jobs
This tool separates structure from style: the HTML structure box decides which elements exist, the CSS box decides how they look, and the right iframe renders live. The benefit of separating is you can tweak selectors without restructuring, which is ideal for iterating on a style.
Good fits:
- Trying selector syntax and specificity — when several rules hit the same element, which actually wins.
- Debugging Flexbox and Grid alignment, spacing and wrapping.
- Checking pseudo-classes and pseudo-elements (
:hover,::before,:nth-child). - Trying CSS variables,
calc()andclamp()and other responsive functions.
Trap 1 — units are measured against the iframe size
The easiest place to draw a wrong conclusion. The preview is an iframe whose size is set by the tool layout, not your browser window. So:
| Unit | Measured against in preview | Consequence |
|---|---|---|
vw | iframe width | differs from the real browser width; ratio distorts |
vh | iframe height | 100vh is only the preview box height, not the screen |
| % (vs viewport) | parent size | same issue |
media query @media (min-width: ...) | judged by iframe width | breakpoints behave nothing like a real device |
So do not use this preview to verify a responsive layout. For media queries, use the device-emulation toolbar in devtools, where you can set the viewport width precisely.
Trap 2 — default styles and inheritance
- The iframe has its own UA defaults. For example body carries about 8px of default margin. So your layout "sits a bit off" is often not your CSS being wrong but a missing reset. Real projects usually import a normalize stylesheet first.
- Fonts differ. The preview's default font may differ from your production environment; font metrics shift line height and wrap points — the same text can wrap a few characters differently.
- The inheritance chain is clean. With no external stylesheet interfering, a global default (such as relying on
* { box-sizing: border-box }) behaves differently in the preview. Write such global settings yourself in the CSS box.
Trap 3 — external resources
As you would expect: relative-path resources (images, font files) will not load, because there is no base URL. Use a full URL or a data URI. To pull in a web font, use a CDN @import or a full link — but remember font loading is asynchronous, so the preview's first paint may differ from the final one (font swap), which can mislead you about line height.
A practical way to read specificity
When debugging a style conflict, the most valuable move is to right-click the preview iframe, choose Inspect, and in devtools' Styles panel see which rules are struck through. A struck-through rule is the one overridden by a higher-priority or later rule — the most direct way to diagnose a conflict, far faster than guessing selector syntax.
Keep the basic priority order in mind: !important > inline style > ID selector > class/attribute/pseudo-class > element/pseudo-element. Within the same level, the later rule wins. The exact weight calculation is useful when tracing.
How the tool works
Write CSS in the left column; when needed, edit the HTML structure box below to supply the elements to act on (editable anytime, handy for trying different tag combos). Hit render and the right side updates instantly. Everything is local, no external service. When moving conclusions into a real project, re-verify in the actual CSS environment — the preview is clean and size-limited, and units and inheritance will differ.
FAQ
Do structure and styles affect each other?
Yes. CSS selectors apply to the HTML you wrote; the two together decide the final look.