An exact px to rem converter

A single pattern substitution over the text you paste. Every number immediately followed by the characters px is captured, divided by the root font size, and rewritten with the unit rem. Nothing else in the input is altered.

That is the complete specification, and the interesting consequences all follow from one word in it: text. This is a substitution over characters, not a transformation of a parsed stylesheet. The converter has no model of a declaration, a property, a comment or a string literal, and it cannot acquire one.

The computation runs in the page. No request is made, which is why there is no run allowance and no length ceiling on this route: both exist to ration a server, and none is involved.

Because the rule is contextless, it fires on any character sequence fitting the pattern regardless of what that sequence means. Three cases are worth knowing by name.

The damaging one is a string literal. An asset referenced as url(icon20px.png) contains the sequence 20px, so it is rewritten to url(icon1.25rem.png) and the reference no longer resolves. Nothing about the output looks wrong, the CSS remains valid, and the image is simply gone. This is the one failure here that produces a broken page rather than an imperfect one.

The other two are semantic rather than destructive. A hairline written as 1px becomes 0.0625rem, converting a value whose entire purpose was to be absolute. A zero written as 0px becomes 0rem, which is valid and pointless. No exclusion mechanism exists for any of the three, so detection is the reader's responsibility and the remedy is manual.

The third step is not a courtesy. Given a contextless substitution, review is the only mechanism that catches a false match.

Step 1

Set the divisor to the root font size the project actually declares.

Step 2

Paste the CSS and convert. Every match is rewritten in one pass.

Step 3

Search the output for url( and for hairline values before the result reaches the codebase.

One parameter is exposed, labelled Root font size, defaulting to 16. It is used directly as the divisor, so the entire output scales inversely with it. At 16, the browser default in practice, the common values resolve cleanly: 12px to 0.75rem, 16px to 1rem, 24px to 1.5rem, 32px to 2rem.

Validation is narrow and explicit. A divisor that is not a finite number, or that is zero or negative, aborts the conversion with the message Enter a valid root font size and leaves the input untouched. Every other positive value is accepted without comment, including ones that produce unpleasant output.

No rounding step exists in the path. The quotient is written out at full floating-point precision, whatever that turns out to be.

At a divisor of 16 this is almost invisible, because 16 is a power of two and the common pixel values divide into short terminating binary fractions. 13px yields 0.8125rem and 11px yields 0.6875rem, both exact and both readable. Move off a power of two and the behaviour changes sharply: at a divisor of 15, 10px yields 0.6666666666666666rem, sixteen significant decimals of a value that has no finite representation.

That number is correct and a browser will handle it correctly. It is simply unreadable in a source file. Competing converters round to two decimal places and accept the small error; this one preserves the value and hands you the formatting problem. Neither choice is wrong, but only one of them is stated, and there is no setting here to switch between them.

Stated so the output is predictable rather than surprising. The numeric part accepts an optional leading minus, so -8px yields -0.5rem, and accepts decimals with or without a leading digit, so .5px is matched. The unit match ignores case, so 20PX is converted, while the emitted unit is always lowercase rem.

Two things prevent a match, and both are useful. Whitespace between the number and the unit means no match, so 20 px survives untouched. And the unit must end at a word boundary, so 20pxx is not matched either. Neither of these is a designed exclusion mechanism, and neither should be relied on as one.

Pixels are absolute and rem units are relative, and the distinction is load-bearing for accessibility rather than stylistic. A length expressed in px is invariant under the reader's own font size preference. A length expressed in rem is a multiple of it, so raising that preference, as readers with low vision or cognitive disabilities commonly do, scales the layout with the text instead of leaving it behind. This is the basis of accessibility guidance on text resizing and readability.

The rationale also delimits itself. It applies to type and to the spacing that surrounds type. It does not apply to a divider intended to be one physical pixel, and converting that value is a regression the accessibility argument does not support. The review step exists precisely because the tool cannot tell the two cases apart.

The dominant case is a remediation pass: an audit finds that text does not resize, and the fix is a unit change applied across an existing stylesheet. The arithmetic is trivial per value and the error rate of doing it several hundred times by hand is not, which is the entire argument for a tool.

The second is translation between a pixel-based design artefact and a rem-based design system. The third, less obvious, is working under a client confidentiality obligation, where the relevant property of this route is not the arithmetic but the absence of a request. The conversion runs from JavaScript already downloaded with the page, so a production stylesheet is never transmitted.