DEV Community: kristy

5 Free PX to REM Converter Tools (and what most of them don't tell you)

kristy — Wed, 19 Aug 2026 14:02:25 +0000

Converting px to rem is basic math — divide by your base font size. Every tool on this list gets that part right. What separates them is whether they tell you the part that actually trips people up: which properties should be in rem, and which ones should deliberately stay in px.

The part the math doesn't tell you

/* Naive "convert everything" approach */
.card {
  padding: 1rem;                 /* 16px → 1rem, fine */
  margin: 1.5rem;                /* 24px → 1.5rem, fine */
  border: 0.0625rem solid #ddd;  /* 1px → 0.0625rem — this is the mistake */
  border-radius: 0.5rem;         /* 8px → 0.5rem, fine */
}

Borders are the classic trap, though not for the reason you usually see given. A 0.0625rem border doesn't render as a blurry sub-pixel — browsers clamp any non-zero border to a minimum of one device pixel, so it stays a crisp hairline. I checked in Chromium across a range of root sizes:

`html { font-size }`	`1px` border	`0.0625rem` border
16px	1px	1px
20px	1px	1px
24px	1px	1px
32px	1px	2px

So it holds at 1px for a long stretch, then silently doubles once the root gets large enough. That's arguably worse than an obvious break, because it only shows up for the users who've turned their font size way up.

The deeper objection is about intent. A hairline border is a visual constant — it separates two things. It isn't a typographic measure, so tying it to font size doesn't express anything meaningful. Same reasoning for most box-shadow blur and spread values, and anything meant to represent one physical device pixel.

Meanwhile the properties that should scale with the user's font preference — padding, margin, gap, border-radius, and obviously font-size itself — are exactly where rem earns its keep. That's the actual accessibility win: someone who bumps their base font size to 20px gets a layout that scales proportionally, not just bigger text crammed into fixed-size boxes.

A converter that just does value / 16 on everything you paste isn't wrong, exactly — but it's not helping you make the property-by-property call either.

Second trap: media query breakpoints

/* Original px-based breakpoint */
@media (min-width: 768px) {
  .container { max-width: 720px; }
}

/* Converted to rem — here rem is genuinely the better choice */
@media (min-width: 48rem) {
  .container { max-width: 45rem; }
}

This one's the opposite case from borders — rem (or em) is actually the better call here, not just a stylistic preference. But the reason is the opposite of what most guides say, and it's worth getting right.

Inside a media query, rem does not follow your html { font-size }. It's always resolved against the browser's initial font size. I tested this by setting the root to 16px, 24px and 32px in turn — @media (min-width: 48rem) fired at a 768px viewport in all three cases, never at 1152px.

That sounds like it defeats the purpose, but it's exactly what makes rem breakpoints valuable. Because they bypass your stylesheet's root override, they track the user's browser font-size setting instead. A reader who's raised their default from 16px to 20px gets breakpoints that shift with them, so the layout reflows at a point that suits their text size rather than at a width you hardcoded. A px breakpoint can't do that, and a rem breakpoint tied to your root wouldn't either.

Third case: line-height and unitless values

/* Common mistake — converting a unitless line-height */
.paragraph {
  font-size: 1rem;
  line-height: 0.09375rem; /* WRONG — this was line-height: 1.5 (unitless), not 24px */
}

/* Correct — leave unitless line-height alone */
.paragraph {
  font-size: 1rem;
  line-height: 1.5; /* scales relative to this element's own font-size */
}

This one's brutal and easy to miss in review. A unitless line-height: 1.5 on 16px text computes to 24px. Run it through a naive converter and you get 0.09375rem, which computes to 1.5px — the lines collapse on top of each other.

The distinction is that a unitless line-height is a ratio, not a length. It multiplies against each element's own font-size, which is exactly why it's the recommended value in the first place: a child with larger text gets proportionally larger leading for free. Converting it to any absolute unit throws that away even when the number happens to work out.

This mostly bites with paste-a-whole-stylesheet tools, but it's worth a grep before you commit a batch conversion.

Fourth case: icon and SVG sizing

/* Icons converted to rem — usually the wrong call */
.icon {
  width: 1rem;   /* was 16px */
  height: 1rem;
}

/* Icons kept in px — generally the right call */
.icon {
  width: 16px;
  height: 16px;
}

Icons are visual assets, not typography — a 16px icon next to 16px text is a deliberate pairing, and letting the icon scale with a user's font-size preference can throw that relationship off. An icon that grows faster or slower than the text beside it looks broken, not "more accessible."

Some design systems do intentionally scale icons with rem to keep the icon-to-text ratio locked, and that's a perfectly valid choice. The point is that it should be a decision you made, not something a converter did to every pixel value it found without telling you.

Fifth case: transform and translate values

/* Converted to rem — technically works, but unusual */
.tooltip {
  transform: translateY(-0.5rem);
}

/* Left in px — the more common convention */
.tooltip {
  transform: translateY(-8px);
}

transform values describe movement distance, not a size tied to typography, so there's no accessibility argument for converting them — an 8px nudge should stay an 8px nudge regardless of the user's font-size setting. Most codebases leave transform offsets in px by convention. A converter that rewrites every number inside transform: isn't breaking anything, but it does scatter rem values through places nobody wanted them.

Here's how five free tools handle the main px-to-rem conversion, and whether they surface any of this.

1. CodeFronts — PX to REM Converter

Best for: knowing which properties to convert, not just doing the math.

Straightforward converter — enter a px value, set your base font size with a slider or number field, get the rem equivalent. There's a preset row for common values and a full reference scale underneath.

What's different is the guidance sitting right next to the tool, in plain language on the page:

Use REM for spacing too — Apply REM to padding, margin, gap, and border-radius, not just font-size. This gives the whole layout scale coherence.

Avoid REM for borders — Keep border-width in px (1px, 2px). Borders should not scale with font size — a 1px border should always be 1px.

That's the exact trap from the first section of this post, called out at the point you're about to fall into it rather than left for you to discover in a bug report three months later. None of the other four tools here say anything about which properties should get converted.

It's also open source — the standalone version is a single 174-line HTML file with no build step and no external requests, so you can fork it or drop it straight into an internal tools page.

🔗 codefronts.com/tools/px-to-rem-converter

2. PixelsConverter

Best for: understanding the formula, not just getting the number.

Less a quick-convert widget, more a working explanation — walks through what the root element is, why 16px is the usual default, and runs the division by hand so you're not trusting a black box.

Formula shown on the page:
rem = px / base font size

Example: 36px ÷ 18px base = 2rem

Good if you're teaching someone the concept rather than doing a fast lookup.

🔗 pixelsconverter.com/px-to-rem

3. nekocalc — PX to REM Converter

Best for: quick back-and-forth conversions in either direction.

Bidirectional — type a px value and get rem, or type rem and get px, with an adjustable base font size.

32px → 2rem   (at 16px base)
2rem → 32px   (reverse direction, same tool)

No guidance about which CSS properties should or shouldn't use rem, but the two-way conversion is genuinely convenient when you're moving between a design spec in px and a stylesheet in rem.

🔗 nekocalc.com/px-to-rem-converter

4. Bug0 — CSS Unit Converter

Best for: converting to units other than rem too.

Handles px, rem, em, %, and pt in one interface with live conversion as you type.

16px = 1rem = 1em = 100% = 12pt
24px = 1.5rem = 1.5em = 150% = 18pt

Plus a reference table converting a long range of px values across all units at once. Useful if you're setting up a design-system scale and want the full unit picture rather than a single lookup.

🔗 bug0.com/tools/px-to-rem-converter

5. CodeBeautify — PX to REM Converter

Best for: a name you already know, if you're already using their other tools.

Does the conversion reliably (16px → 1rem, 20px → 1.25rem, standard division). Part of CodeBeautify's much larger suite of format and unit converters, so if you're already there for something else it's a reasonable one to bookmark alongside it. No specific guidance on which properties to convert vs. leave in px.

🔗 codebeautify.org/px-to-rem-converter

Short version

Want the "which properties" guidance built in → CodeFronts
Learning the concept, not just converting → PixelsConverter
Need both directions (px↔rem) → nekocalc
Setting up a full unit scale (px/rem/em/%/pt) → Bug0
Already using CodeBeautify for other conversions → CodeBeautify

Whichever tool you use, the conversion math is the easy part. The judgment call is knowing that your borders and shadows probably shouldn't scale with the rest of your layout — and that your breakpoints probably should.

Do you convert your whole stylesheet to rem up front, or only the properties that actually need to scale? Curious what other people land on here.

5 Free SCSS to CSS Converter Tools (and the one thing most get wrong)

kristy — Fri, 14 Aug 2026 11:30:00 +0000

Every "convert SCSS to CSS online" tool handles a basic variable substitution fine. Where they actually differ is the trickier stuff — the & parent-reference, what happens to $variables, and whether nested @media gets hoisted the way Sass does it.

I ran the same three SCSS blocks through five free converters to see where each one holds up. (Tested August 2026 — these tools update, so re-check before trusting any of this on a real file.)

Test 1: The `&` parent-reference

This is the single most common manual-conversion mistake, and it's where weak tools fall apart too.

/* Input SCSS */
.card {
  padding: 1rem;

  &:hover {
    box-shadow: 0 4px 12px rgba(0,0,0,0.1);
  }
}

There are two ways to get this wrong:

/* WRONG — space before :hover selects a hovered descendant, not the card itself */
.card {
  padding: 1rem;
}
.card :hover {
  box-shadow: 0 4px 12px rgba(0,0,0,0.1);
}

/* CORRECT — no space, & concatenates directly onto the parent */
.card {
  padding: 1rem;
}
.card:hover {
  box-shadow: 0 4px 12px rgba(0,0,0,0.1);
}

That single space changes the selector's meaning entirely — one selects the card on hover, the other selects something inside the card while it's hovered. Sass always concatenates & with no space.

A harder version of the same test — comma-separated parents, which should expand cartesian:

/* Input SCSS */
.a, .b {
  & > .c {
    color: red;
  }
}

/* Correct output */
.a > .c, .b > .c {
  color: red;
}

Most lightweight converters handle the simple &:hover case but choke on the comma-separated version.

Test 2: Variable handling

/* Input SCSS */
$brand: #7c3aed;
$radius: 8px;

.button {
  background: $brand;
  border-radius: $radius;
}

Two useful outputs, depending on what you're actually trying to do:

/* Inline mode — matches Sass's actual compile output */
.button {
  background: #7c3aed;
  border-radius: 8px;
}

/* CSS custom-property mode — not what Sass emits, but often what you want */
:root {
  --brand: #7c3aed;
  --radius: 8px;
}
.button {
  background: var(--brand);
  border-radius: var(--radius);
}

Worth being clear that only the first is a real Sass compile — $variables are resolved at build time and don't exist in the output. The second is a migration convenience: if you're dropping Sass from a codebase, converting $vars to custom properties gives you runtime theming that $variables never had in the first place. Most converters only offer inline mode.

Test 3: Nested `@media`

/* Input SCSS */
.container {
  padding: 1rem;

  @media (min-width: 768px) {
    padding: 2rem;
    max-width: 720px;
  }
}

Sass hoists the @media block to the top level:

/* Correct output — hoisted */
.container {
  padding: 1rem;
}
@media (min-width: 768px) {
  .container {
    padding: 2rem;
    max-width: 720px;
  }
}

A tool that does a naive flatten and leaves @media sitting inside .container { } isn't producing invalid CSS anymore — native CSS Nesting has been widely supported since 2023–24, so that form works in current browsers. But it isn't what Sass emits, it won't match a real build's output, and it breaks in any browser matrix that still includes pre-nesting versions. If the point of converting is to get the same CSS your Sass build produces, unhoisted output has failed the job.

Now, how the five tools handled all three.

1. SassMeister

Best for: older SCSS with mixins, @extend, and control directives.

Passes all three tests — it runs an actual Sass compiler rather than a simplified parser, so mixins, @extend, and control directives work.

The catch is the version. SassMeister compiles against Ruby Sass 3.x and LibSass, both long since retired — Ruby Sass hit end of life in 2019, LibSass was deprecated in 2020. So modern syntax doesn't work: no @use, no @forward, no sass:math / sass:color modules. lighten() and darken() still run, but those are the deprecated API. Treat it as excellent for legacy Sass, not current Sass.

🔗 sassmeister.com

2. CodeFronts — SCSS to CSS Converter

Best for: the harder & cases, and knowing what got skipped instead of guessing.

Passed all three tests, including comma-separated parent expansion and full @media hoisting. Two things stood out:

Both variable modes are available — inline for a one-off snippet, CSS custom properties for a codebase migration.
Unsupported features get flagged, not silently dropped. Paste something with @mixin, @extend, or a Sass color function and it warns you which feature it skipped, so you know what needs a hand-audit against a real Sass build.

It also evaluates same-unit math in place (padding: 12px + 4px → padding: 16px), which none of the other four here do.

Where it loses: it's a browser-only subset of SCSS, not a compiler. Multi-file @use/@forward setups and anything needing real mixin argument-binding still need Sass installed locally. If your input actually uses mixins, SassMeister will get you further.

🔗 codefronts.com/tools/scss-to-css-converter

3. CSS Portal — SCSS to CSS Compiler

Best for: a quick paste-and-compile on straightforward nesting.

Handled all three tests correctly, including the comma-separated & case — better than I expected from a tool this minimal, and better than the two below it here.

Its one gap is silence: like most lightweight converters, it doesn't tell you which SCSS features it couldn't handle. Paste something using mixins or color functions and you get quietly incomplete output rather than a warning. If your input is plain nesting and variables, though, it does the job with no ceremony.

🔗 cssportal.com/scss-to-css

4. CodeBeautify — SCSS to CSS Converter

Best for: simple snippets, when you want a name you already trust.

Solid on the basics — simple nesting, variable inlining, @media hoisting — but less reliable on the comma-separated & case. Part of a much larger suite of format converters, so it's a reasonable default if it's already in your bookmarks for other things.

🔗 codebeautify.org/scss-to-css-converter

5. GeeksforGeeks — SCSS to CSS Converter

Best for: a fast answer with nothing to configure.

Handled the simple &:hover case and basic variable inlining fine. The comma-separated parent case didn't expand cleanly, and the nested @media came out only partially hoisted. Inline values only, no custom-property option.

🔗 geeksforgeeks.org/utilities/scss-to-css-converter

Results at a glance

	`&` simple	`&` comma parents	Variable modes	`@media` hoisting	Flags what it skipped
SassMeister	✅	✅	Inline	✅	N/A — real compiler
CodeFronts	✅	✅	Inline + custom props	✅	✅
CSS Portal	✅	✅	Inline	✅	❌
CodeBeautify	✅	⚠️ partial	Inline	✅	❌
GeeksforGeeks	✅	⚠️ partial	Inline	⚠️ partial	❌

Short version

Legacy SCSS with mixins and @extend → SassMeister (mind the old compiler)
Harder & cases, or you want to know what got skipped → CodeFronts
Plain nesting, fast, no options → CSS Portal
Already in your bookmarks → CodeBeautify
Quick one-off → GeeksforGeeks

And honestly: if you're converting anything beyond snippets, install Sass and run it. Every browser-based converter is a subset, and the ones that don't tell you which subset are the risky ones.

Whichever you pick, run the comma-separated & case and a nested @media block through it before trusting it on a real file — those two are where most converters, and most manual conversions, quietly get it wrong.

What's your usual move — keep Sass around for one project's build step, or convert and drop the dependency?

Where I actually get CSS buttons (and what breaks when you paste them in)

kristy — Thu, 13 Aug 2026 10:30:00 +0000

I've been collecting CSS button sources for a while — partly because I keep needing them, partly because I got tired of pasting a snippet and then spending twenty minutes fixing it.

So I sat down and actually tested six of them. Not "looked at the homepage" tested — pulled buttons out, dropped them into a real project, checked them on a mid-range Android and with a keyboard.

Here's what I found, starting with why the pasting-and-fixing cycle happens at all.

The three things that make a pasted button need rewriting

1. It animates the wrong properties.

This is the big one, and it's invisible on your dev machine. A hover effect that animates width, height, top, margin, or box-shadow forces the browser to recalculate layout or repaint on every frame. On an M-series laptop it looks fine. On a mid-range Android it stutters.

/* Costs layout on every frame */
.btn:hover {
  margin-top: -4px;
  box-shadow: 0 8px 16px rgba(0,0,0,.3);
}

/* Compositor-only — runs on the GPU, no layout, no repaint */
.btn::after {
  box-shadow: 0 8px 16px rgba(0,0,0,.3);
  opacity: 0;
  transition: opacity .2s;
}
.btn:hover { transform: translateY(-4px); }
.btn:hover::after { opacity: 1; }

The rule of thumb: transform, opacity, and filter are cheap. Almost everything else isn't. If you want the shadow to animate, put it on a pseudo-element and fade that in.

Want to check a snippet before committing to it? DevTools → Rendering → Paint flashing. Hover the button. Green flashes mean repaints.

2. It styles :hover and forgets :focus-visible.

A surprising number of copy-paste buttons have a beautiful hover state and nothing at all for keyboard users — or worse, outline: none with no replacement. That's a real accessibility failure, not a nitpick.

.btn:focus-visible {
  outline: 2px solid currentColor;
  outline-offset: 2px;
}

:focus-visible rather than :focus means mouse users don't get a ring on click, but keyboard users do. Two lines. Add them to anything you paste.

3. It ignores prefers-reduced-motion.

If your button bounces, scales, or ripples, some people need it not to. Wrap the motion, keep the state change:

@media (prefers-reduced-motion: reduce) {
  .btn, .btn::after { transition-duration: .01ms; animation: none; }
}

Now, the sources.

1. Uiverse.io

Best for: browsing by vibe when you don't know what you want yet.

Community-driven, so the variety is enormous — hundreds of button styles from subtle to genuinely unhinged. Live preview before you copy, mostly pure CSS/HTML with some Tailwind versions.

The trade-off is exactly what you'd expect from community submissions: quality varies a lot by contributor. Plenty of these animate layout properties, and accessibility isn't enforced. I treat it as inspiration I'll clean up, not code I'll ship as-is.

🔗 uiverse.io/elements?tags=button

2. CSS Scan — Beautiful CSS Buttons

Best for: clean, conventional buttons you'd actually put in a real product.

A curated collection of 92 free CSS buttons, click-to-copy. Much more restrained than Uiverse — these read as "designed by someone with taste" rather than "look what I can do with clip-path." My default when I need something for a dashboard or a marketing page.

Heads up: the buttons page is free, but it's a funnel for the paid CSS Scan extension. Nothing wrong with that, just know what you're on.

🔗 getcssscan.com/css-buttons-examples

3. CodeFronts — CSS Buttons

Best for: button states, not just button looks.

51 buttons covering the things that usually get skipped: form/submit buttons, icon buttons with accessible tooltips, loading states, disabled states, plus some click-effect studies (magnetic ripple, glitch, neon burst).

This is the one that made me write the first half of this post. The animations are compositor-only (transform, opacity, filter), :focus-visible and reduced-motion are handled by default, and the demos hold up at 320/600/1440px. I pasted three of these in without changing anything, which I can't say about the rest of the list.

Where it loses: 51 is small. Uiverse has an order of magnitude more variety, and if you want something visually wild you'll find it there and not here. This is a "handled correctly" collection, not a "biggest" one.

🔗 codefronts.com/components/css-buttons

4. Hover.css

Best for: when you want a stylesheet, not snippets.

Ian Lunn's library — 100+ hover effects as utility classes you drop onto existing elements. Instead of copying a whole button, you add hvr-grow or hvr-sweep-to-right to the button you already have. Available in CSS, Sass, and LESS.

Check the license before using this commercially. It was MIT before v2.2.0 (March 2017), but current versions require a commercial license for commercial use. I've seen this shipped without anyone noticing.

🔗 ianlunn.github.io/Hover

5. CodersEra — CSS Button Hover Effects

Best for: understanding the technique instead of copying it.

Less a library, more a reference. Each effect comes with full code plus an explanation of what's actually happening — which properties are doing the work and why. Genuinely useful when you want to adapt an effect to your design system rather than paste it verbatim.

Not where you go if you're in a hurry.

🔗 codersera.com/blog/best-top-50-css-button-hover-effects

6. cssbuttons.app

Best for: a quick, no-friction grab.

60+ handpicked CSS buttons. Smaller than the others and the collection doesn't seem to update often, but the interface is fast and there's no signup. Worth a look when the bigger sites are giving you too many options.

🔗 cssbuttons.app

Short version

Don't know what you want → Uiverse
Want tasteful defaults → CSS Scan
Care about states and a11y → CodeFronts
Want utility classes → Hover.css (check the license)
Want to learn the technique → CodersEra
Want it fast → cssbuttons.app

Whichever you pick, add the :focus-visible block and the reduced-motion query. Most snippets on the internet don't have them.

What's your paint-flashing horror story? I once shipped a nav where every link animated letter-spacing on hover. Looked incredible. Dropped the page to about 12fps on scroll.

DEV Community: kristy

5 Free PX to REM Converter Tools (and what most of them don't tell you)

The part the math doesn't tell you

Second trap: media query breakpoints

Third case: line-height and unitless values

Fourth case: icon and SVG sizing

Fifth case: transform and translate values

1. CodeFronts — PX to REM Converter

2. PixelsConverter

3. nekocalc — PX to REM Converter

4. Bug0 — CSS Unit Converter

5. CodeBeautify — PX to REM Converter

Short version

5 Free SCSS to CSS Converter Tools (and the one thing most get wrong)

Test 1: The & parent-reference

Test 2: Variable handling

Test 3: Nested @media

1. SassMeister

2. CodeFronts — SCSS to CSS Converter

3. CSS Portal — SCSS to CSS Compiler

4. CodeBeautify — SCSS to CSS Converter

5. GeeksforGeeks — SCSS to CSS Converter

Results at a glance

Short version

Where I actually get CSS buttons (and what breaks when you paste them in)

The three things that make a pasted button need rewriting

1. Uiverse.io

2. CSS Scan — Beautiful CSS Buttons

3. CodeFronts — CSS Buttons

4. Hover.css

5. CodersEra — CSS Button Hover Effects

6. cssbuttons.app

Short version

Test 1: The `&` parent-reference

Test 3: Nested `@media`