Percentage to PX Converter
Percentages to pixels with the basis named per property, including the one everybody trips on: percentage padding resolves against width, even top and bottom.
Property width, min-width, max-width, left, right
Measured against the containing block's width
That reference 1200px
Percentage 25%
In pixels 300px
In rem 18.75rem
Against 1200px
5% 60px
10% 120px
12.5% 150px
20% 240px
25% 300px
33.333% 400px
50% 600px
66.667% 800px
75% 900px
80% 960px
90% 1080px
100% 1200px
On width, min-width, max-width, left, right, a percentage is measured
against the containing block's width. At 1200px that makes 25% come to
300px.
Percentages need a resolved reference to work from. A percentage height
inside a parent with no set height has nothing to resolve against, so
the browser treats it as auto, which is the usual reason "height: 100%"
appears to do nothing.
Rounding is the browser's, not yours. Sub-pixel layout means three
columns at 33.333% do not add up to the container, and the leftover
fraction shows up as a hairline gap at some zoom levels. Use a grid or
flexbox rather than percentages for anything that has to divide evenly.
Output is valid and updates as you type.
Fix the highlighted fields to update the output.
Twenty-five percent of 1200px is 300px. The division is not the question. The question is a percentage of what, and CSS answers it differently depending on which property you wrote it on.
Width is of the containing block’s width. Font-size is of the parent’s font size. Line-height is of the element’s own font size, which is not the parent’s. And padding or margin in percent is of the containing block’s width on every side, including top and bottom.
That last one is not a browser quirk. It has been in the specification since CSS 2, it is what made the old padding-top aspect-ratio box work, and it is why a vertical percentage padding looks wrong when the window gets wide.
How to use
- Pick the property the percentage is written on. This is the important field.
- Put in the size it is measured against, in pixels.
- Read the conversion, and the table of common percentages.
- Put a pixel value in the reverse field to go the other way.
Example
25% on a padding, against a 1200px containing block:
Property padding or margin, any side
Measured against the containing block's width, even on the top and bottom
That reference 1200px
Percentage 25%
In pixels 300px
In rem 18.75rem
Against 1200px
5% 60px
10% 120px
12.5% 150px
20% 240px
25% 300px
33.333% 400px
50% 600px
66.667% 800px
75% 900px
80% 960px
90% 1080px
100% 1200pxpadding-top: 25% on that element is 300px of vertical space, and it came from the
width. Make the container 2000px wide and the vertical padding becomes 500px, with
nothing about the height involved.
Pitfalls
Percentage padding and margin resolve against width. On all four sides. This is the one that costs people an afternoon.
Percentage font sizes compound. Three nested elements at 90% each end up at 72.9%
of the root, which is how a deep component ends up with 11px text nobody chose. rem
does not compound, and that is the argument for it.
A percentage line-height inherits as a computed length. line-height: 150% on a
parent is resolved there, against the parent’s font size, and the resulting pixel value
is what children inherit. A child with larger text keeps the parent’s line height and
looks cramped. A unitless line-height: 1.5 inherits as a ratio and recomputes per
element, which is why unitless is the right default.
A percentage height needs a resolved parent height. If the parent’s height is
auto, there is nothing to resolve against and the browser treats the child’s
percentage as auto too. That is the usual reason height: 100% appears to do nothing.
Sub-pixel rounding leaves gaps. Three columns at 33.333% do not add up to the container, and the remainder shows up as a hairline at some zoom levels. For anything that has to divide evenly, use grid or flexbox rather than percentages.
A transform percentage is of the element, not the parent.
transform: translateX(-50%) moves the element by half its own width, which is what
makes the centring trick work and what makes it behave oddly on an element whose width
depends on its content.
Compatibility
Arithmetic in the browser: nothing is uploaded and nothing is stored. The share link carries the figures.
The per-property bases here are from CSS Box Model and CSS Values and Units, and they have been consistent across browsers for a long time: the percentage padding rule goes back to CSS 2, and every engine agrees on it. This is not a compatibility list; it is a specification list.
Two modern properties reduce how often you need any of this. aspect-ratio replaces
the padding-top box, and gap replaces percentage margins between grid and flex items.
Both are in every current browser, and both are easier to reason about than a
percentage whose basis you have to look up.
Frequently asked questions
Why does percentage padding use the width?
What is 100% of?
How do I convert a percentage to px without knowing the container?
Should I use percentages or rem for spacing?
rem for spacing that should follow the type, which is most spacing. Percentages for
spacing that should follow the container’s width, which is occasionally what a fluid
layout wants. gap for the space between items in a grid or flex container.Why did my 50% width element not sit in half the row?
box-sizing is content-box.
With border-box, 50% includes the padding and the border, which is nearly always the
behaviour you wanted.