PT to PX: Points to Pixels Conversion Table and Rules

PT to PX: Points to Pixels Conversion Table and Rules

In CSS, 12pt equals 16px. Multiply any point size by 4/3 (about 1.3333) to get pixels, and multiply pixels by 0.75 to get points. The ratio is fixed because the CSS specification defines one inch as exactly 96px and exactly 72pt, so it never depends on the screen, the browser or the font.

That fixed ratio holds only inside CSS. Type the same "12" into Photoshop at 300 pixels per inch and the text is 50 pixels tall. Type it into an iPhone layout and it is 12 points that become 24 or 36 device pixels depending on the screen. A Windows app set to 125 percent display scaling draws a 12-point font 20 pixels tall. Every one of those numbers is correct for its own system, and most conversion mistakes in design handoffs come from applying one system's ratio to another's file.

Where the 4/3 Ratio Comes From

CSS Values and Units Module Level 4 lists the absolute length units as a set of fixed relationships: "1in = 2.54cm = 96px", "1pt = 1/72nd of 1in" and "1px = 1/96th of 1in". It also defines the pica as one sixth of an inch, which MDN's length reference restates as "1pc = 12pt = 1in / 6". Put the two inch definitions side by side and the conversion falls out with no measurement involved:

• 72pt = 1in = 96px
• so 1pt = 96 / 72 px = 4/3 px, about 1.3333px
• and 1px = 72 / 96 pt = 3/4 pt, exactly 0.75pt

The spec adds that these units "are mainly useful when the output environment is known", which is the polite way of saying that on screens a CSS inch is not a ruler inch. The reason is the reference pixel. CSS 2.2 defines it as "the visual angle of one pixel on a device with a pixel density of 96dpi" held at arm's length, and gives the numbers: at a nominal arm's length of 28 inches the angle is about 0.0213 degrees, and 1px corresponds to about 0.26 mm. Screens and other low-resolution devices anchor the whole unit family to that pixel. Print and similar high-resolution devices anchor it to a physical unit instead, so that on paper an inch really is an inch.

MDN spells out the consequence for screens: because 1in is defined as 96px, "which equals 72pt", dimensions in inches, centimetres or millimetres "don't necessarily match the size of the physical unit with the same name". A 72pt heading in CSS is always 96 CSS pixels tall. Whether that is one physical inch on your monitor depends on the monitor, its scaling setting and the browser zoom, and none of those change the pt to px ratio.

The pillar guide on px, rem and em units covers what a CSS pixel is in relation to device pixels. For conversion, the only fact you need is the one the spec fixes: 3 points for every 4 pixels.

The Conversion Table, 6pt to 96pt

The table below was generated by a short Python script for this guide using exact fractions, then rounded only for display. The px column shows the exact value where it is not a whole number, because 7pt is not "9px" or "9.3px" but 28/3 px. The rem column assumes a 16px root, the common browser default that MDN describes, and the last column gives the physical size on paper at 25.4 mm per inch.

One pattern is worth remembering because it saves a calculator trip. A point size converts to a whole number of pixels only when it is a multiple of 3: 6, 9, 12, 15, 18, 21, 24, 30, 36, 42, 48, 54, 60, 72 and 96 all land on integers. Everything else carries a third or two thirds of a pixel. That is why print-derived type scales built on 10, 11, 14 and 16 points produce awkward web values, while a scale built on 9, 12, 18 and 24 points converts cleanly to 12, 16, 24 and 32 pixels.

A second pattern: the rem column is simply the pt value divided by 12, because 12pt is 16px is 1rem at the default root. So 18pt is 1.5rem and 30pt is 2.5rem. You can skip pixels entirely when the target is rem and the root is untouched.

Pixels Back to Points

The reverse direction comes up when a web design has to become a print document, a PDF export or a slide template. Multiply by 0.75. Since 0.75 is exact, every result below is exact too, with no rounding at all.

If the target app accepts decimal point sizes, type 9.75pt or 11.25pt as they are. If it only takes whole or half numbers, round and note it in the handoff, because a 15px caption that becomes 11pt in a print version is 2.2 percent smaller than the web original (11 / 11.25 = 0.978).

From a Print Spec to a Scalable Web Size

Converting pt to px is usually a middle step rather than the goal. A brand guide written for print says body text is 11pt and headings are 24pt. The web build should not end up with font-size: 11pt, and it should not end up with 14.67px either, because both are absolute lengths. MDN's length reference warns that absolute lengths "do not scale according to user settings" and that relative units such as em or rem are preferred for font-size. A reader who set their browser's default text to 20px gets nothing from a value written in pt or px.

The usual route is pt to px to rem, then let the root do its job:

1. Convert with the table: 11pt is 44/3 px, 24pt is 32px.
2. Divide by the 16px default root: 11pt is 0.9167rem, 24pt is 2rem.
3. Write the rem values in the stylesheet and leave the html element's font size unset or set as a percentage.

At default settings the page renders exactly as the print guide intended: 14.67px body text and 32px headings. For a reader whose default is 20px, the same rem values give 18.33px and 40px, preserving the ratio between body and heading that the brand guide cared about. The px to rem converter runs step 2 if you prefer not to divide by hand, and it is worth checking its root size field matches the root you actually ship.

A quick worked set, taking a typical print hierarchy and carrying it all the way through:

Two judgement calls sit inside that table. First, an 8pt caption works on paper read at close range but becomes 10.67px on screen, which is small for body copy on most layouts. Print sizes were chosen for print viewing distances, so converting them faithfully is not the same as choosing good screen sizes. Many teams take the print ratios and rebuild the scale for the screen, which is the approach the typography scale guide walks through. Second, three decimal places in a rem token keep the rounding error below a thousandth of a rem, which at a 16px root is 0.016px. Rounding 0.9167rem to 0.9rem, by contrast, shifts body text by about a quarter of a pixel (0.0167 x 16 = 0.27px) and changes every line break calculation that depends on it.

Why the Same "12pt" Comes Out Different Sizes

The 4/3 ratio is a CSS rule. Other software defines points and pixels in its own way, and each definition is reasonable in its own setting. The table summarises what a value of 12 means in seven places, with the arithmetic shown so you can recheck it. All of it was computed for this guide from the definitions cited in each section below.

The CSS rows are the only ones where 12 points and 16 pixels are the same thing by definition. Everywhere else the pixel count depends on a resolution setting that belongs to the document or the device. Each row is explained below.

CSS in a browser

A browser computes 12pt as 16 CSS pixels on every screen. The device then draws those 16 CSS pixels with however many physical pixels it has; MDN notes that on printers and high-resolution screens "one CSS pixel implies multiple device pixels". A 12pt label on a laptop with a device pixel ratio of 2 uses 32 device pixels of height for its em box, and on a phone with a ratio of 3 it uses 48. You never write those numbers in CSS. They matter only when you export raster images for the slot, which is the subject of the responsive images guide.

Word processors on Windows

Microsoft's Win32 documentation on DPI explains how Windows treats type, and its worked example lands on the same number CSS does. One point is 1/72 of an inch, and "a 72-point font is defined to be one logical inch tall". For many years Windows converted one logical inch to 96 pixels, so "a 12-point font is 16 pixels tall". The document calls that scaling factor 96 DPI and lists the standard settings as 100% (96 DPI), 125% (120 DPI) and 150% (144 DPI).

That is why a 12pt document on a Windows laptop at 100 percent scaling and zoom shows text the same size as 16px text in a browser on the same screen. Change the display scaling to 125 percent and Windows draws the 12-point font with 20 pixels; at 150 percent, 24 pixels. The document is still 12pt, it still prints at one sixth of an inch, and the CSS conversion has not changed either. Only the number of screen pixels used to show it has. The page also notes that Microsoft's definition of the point is "the desktop publishing definition" and that "historically, the exact measure of a point has varied", which matters in the Photoshop section below.

Browser-based editors, such as Google Docs or Word for the web, show their documents through a browser, so on screen they are subject to the browser's own zoom and the operating system's scaling as well. We did not test how any particular online editor maps its point sizes to CSS internally, so treat the browser rule (12pt = 16 CSS px at 100 percent zoom) as a starting expectation to check, not a guarantee for every app.

Photoshop and other raster editors

In Photoshop a point is tied to the document's resolution. Adobe's help page on formatting characters says that "points is the default unit of measurement for type" and defines the unit: "One PostScript point is equal to 1/72 of an inch in a 72-ppi image." Type that is 12 points tall is one sixth of a document inch, and the document's PPI decides how many pixels that inch holds.

• At 72 ppi, one sixth of an inch is 12 pixels, so 12pt type is 12 pixels.
• At 150 ppi it is 25 pixels.
• At 300 ppi it is 50 pixels.

This catches people who design web graphics in a document that was set up for print. A 1200 by 630 pixel social image created at 300 ppi with 12pt caption text ends up with 50-pixel captions, more than three times the 16px the designer had in mind. The pixels are what count in the exported file; the PPI tag has no effect when a browser displays an image, as the DPI and PPI guide explains. Two habits avoid the surprise: set web documents to 72 ppi so that points and pixels match one to one, or switch Photoshop's type unit to pixels in Units and Rulers preferences, which Adobe's page names as the place to change it.

Adobe's page also lists a second option under Point/Pica Size: "Traditional (72.27 points/inch)", next to "PostScript (72 points/inch)". The traditional point is about 0.4 percent smaller. At 12pt and 300 ppi it produces 49.81 pixels rather than 50, which is invisible on screen but can matter when a file has to match a measured print sample. CSS, Windows and the PostScript setting all use 72 per inch.

iOS points

Apple uses the word "point" for something different again. In UIKit, the documentation for a screen's scale property says the default logical coordinate space "is measured using points", and that the scale factor converts it into device pixels: on standard-resolution displays the scale factor is 1.0 "and one point equals one pixel", and on Retina displays it may be 3.0 or 2.0, where one point is represented by nine or four pixels (three by three, or two by two).

An iOS point is therefore a logical unit, like a CSS pixel, not 1/72 of an inch. Apple's Human Interface Guidelines list the default text size for iOS and iPadOS as 17 pt with a minimum of 11 pt, and those 17 points become 34 device pixels on a 2x screen and 51 on a 3x screen. What they do not become is 22.67 CSS pixels. The pt in an iOS spec and the pt in CSS share a name and nothing else.

Android dp and sp

Android avoids the word point for screen layout. Its "Support different pixel densities" page defines the density-independent pixel as "a virtual pixel unit that's roughly equal to one pixel on a medium-density screen (160 dpi, or the 'baseline' density)", and gives the conversion as px = dp x (dpi / 160). For text it uses the scalable pixel: the sp "is the same size as a dp, by default, but it resizes based on the user's preferred text size".

So 12sp is 12 pixels on an mdpi (~160 dpi) screen, 24 on xhdpi (~320 dpi) and 36 on xxhdpi (~480 dpi), before any user text-size change. Android's page tells developers not to hard-code that formula and to let the system's TypedValue.applyDimension() do the conversion. Like the iOS point and the CSS pixel, the dp is a logical unit, and like rem on the web, sp is the one that follows the user's text preference.

Print

On paper the anchor flips. CSS 2.2 says that for print media and similar high-resolution devices "the anchor unit should be one of the standard physical units", so a 12pt rule in a print stylesheet means 12/72 of a real inch: one sixth of an inch, or 4.23 mm. Word processors print the same way. Microsoft's DPI page describes the physical idea behind it: "a 12-point font is designed to fit within a 1/6" (12/72) line of text."

A unit conversion changes the font size value exactly, but it cannot make two typefaces look alike. Letter shapes differ in how much of the font size they fill, so 12pt in one family can look larger or smaller than 12pt in another. When a web font replaces the print font, compare the two at real size rather than trusting the number alone.

Carrying a Mobile Spec Over to the Web

The table above leads to a practical rule that trips up a lot of handoffs: a size taken from an iOS or Android spec should usually be carried to CSS as the same number in px, not converted from pt.

The reasoning, which is ours and not a statement from Apple, Google or the W3C, runs like this. A CSS pixel, an iOS point and an Android dp are all logical units that the platform multiplies by a density factor to get device pixels. Each is defined so that one unit looks roughly the same size on that platform's typical devices. The CSS reference pixel is pegged to a 96dpi screen at arm's length; the Android dp to a 160 dpi baseline; the iOS point to the 1x screen where one point was one pixel. Converting an iOS "17 pt" through the 4/3 CSS ratio would treat it as a physical typographic point, which it is not, and would inflate the body text by a third.

So when a mobile design system says body text is 17pt, the web counterpart is 17px, or 1.0625rem at a 16px root. If an Android spec gives a label as 14sp, the web counterpart is 14px, or 0.875rem. This is a starting point, not a pixel-identical match: phones are held closer than laptops, and each platform's text renders with its own font metrics. Test at real size on a device before freezing the token.

The same logic applies to touch targets. Apple's accessibility guidelines give 44x44 pt as the default control size on iOS and iPadOS, and Android's accessibility page recommends touch targets of at least 48dp by 48dp. Both are logical sizes. They map to 44 and 48 CSS pixels, not to 58.67 and 64. The touch target size guide works through those platform numbers against WCAG's own pixel thresholds.

When pt Belongs in a Stylesheet

Points are not wrong in CSS. They are just suited to one job: output where the physical size is known. The spec's own wording, "mainly useful when the output environment is known", describes print.

A print stylesheet is the clearest case. Inside @media print, a rule such as body { font-size: 11pt; } is read by the browser's print engine as eleven 72nds of a physical inch, the same unit the reader's office software and printer driver use. Margins in cm or mm behave the same way. If your screen styles use rem, the print styles can switch to pt with no conversion at all, because the target is paper and the reader's screen text preference no longer applies to the sheet being printed.

There are a few other places where pt shows up and is reasonable:

• HTML email and documents converted to PDF, where the output is often a fixed page and the conversion tools expect print units. Check the tool's documentation; some treat pt as CSS pt and some as their own logical unit.
• Matching a printed proof. If a web preview of a business card or label has to show the type at its print size, using pt values from the print file keeps the numbers identical between the two, even though the screen version is a CSS inch, not a ruler inch.
• Legacy stylesheets. Older sites sometimes set body text in pt. The result on screen is identical to the px equivalent (12pt renders as 16px), and carries the same accessibility problem: neither follows the reader's font-size setting. Converting those rules to rem is the fix, and the table above gives the values.

What pt should not do is set screen body text or the root font size. html { font-size: 12pt; } is exactly html { font-size: 16px; }, and both overwrite whatever default the reader chose. The pillar guide's section on the root size explains why percentage or no value is the safer choice there.

Thirds of a Pixel: What to Do With Fractional Results

Because two of every three point sizes convert to a fraction, a team needs a rule for the remainders. The CSS values are not a problem in themselves: font-size: 14.6667px is valid CSS, and a rem value with four decimals is perfectly normal. Where fractions cause trouble is in design tokens, handoff documents and tests that compare numbers.

A sensible order of preference:

1. Keep the value relative and keep the decimals. 0.9167rem written as-is, or rounded to three places (0.917rem), keeps the rounding below 0.02 CSS pixels at the default root. Nobody can see that.
2. If the team works in whole pixels, round once and say so. 11pt becomes 15px in the token file with a comment that the print guide says 11pt. Rounding 14.67 up to 15 is a 2.3 percent increase; rounding 10.67 (8pt) down to 11 is a 3.1 percent increase. Record which way you went so the next conversion does not round a rounded number again.
3. If the scale is new, choose point sizes that are multiples of 3. 9, 12, 15, 18, 24, 30 and 36 pt all convert to whole pixels (12, 16, 20, 24, 32, 40, 48) and to clean rem values (0.75, 1, 1.25, 1.5, 2, 2.5, 3). It is the cheapest way to make a print and a web scale agree exactly.

Line height is a separate number. If the print guide gives leading as a point value, convert it to a ratio of the font size (13.2pt leading on 11pt type is 1.2) and write that unitless number, which the pillar guide recommends for line-height; the ratio then survives any font-size conversion.

Five Handoff Errors and What Fixes Each One

These are the conversion errors that produce text at the wrong size even when everyone did their arithmetic correctly. Each has a single cause, so each has a single fix.

1. Converting iOS or Android sizes with the 4/3 ratio. A 17pt iOS body size becomes 22.67px on the web and the site's text looks oversized next to the app. Fix: treat platform points and dp as CSS pixels, as shown in the mobile section above.

2. Reading font sizes off a Photoshop file set to 300 ppi. The developer sees "12pt" in the type panel and writes 16px, but the text in the exported mockup is 50 pixels tall. Or the developer measures the pixels and writes 50px when the designer intended something near 16. Fix: set web mockups to 72 ppi or switch the type unit to pixels before handing the file over.

3. Measuring a screenshot from a high-density screen. A screenshot from a 2x laptop has twice as many pixels as the CSS layout. A 16px heading measures 32 pixels in the image, and someone converts 32px back to 24pt for a print version that comes out at double size. Fix: divide screenshot measurements by the device pixel ratio first, or measure in the browser's developer tools, which report CSS pixels.

4. Keeping pt for screen text "because the brand guide uses points". The page looks right at default settings and ignores every reader who raised their text size. Fix: convert to rem as in the worked set above; the print guide's proportions survive intact.

5. Trusting "72 DPI" as a screen fact. Some converters still assume 72 pixels per inch for screens, which makes 12pt equal 12px. That number is wrong for CSS, which fixes 96px per inch, and wrong for Windows, which uses 96 logical pixels per inch at 100 percent scaling. It is only right inside an image editor whose document happens to be set to 72 ppi. Fix: for any web value, use 4/3.

A Rule That Works for Any pt Value

Before converting a number, ask where it came from. The answer picks the formula:

• From a print document, a word processor, a PDF or a CSS stylesheet: it is a 1/72-inch point. For the web, multiply by 4/3 to get px, or divide by 12 to get rem at the default root. For paper, it is already the final size.
• From an iOS spec: it is a logical point. Use the same number in CSS px, then divide by 16 for rem.
• From an Android spec in dp or sp: it is a logical density-independent unit. Use the same number in CSS px; sp maps best to rem because both follow the user's text size.
• From an image editor's type panel: it depends on the document's PPI. Multiply by ppi / 72 to get the pixels that are actually in the file, then decide what CSS size you want, which is a design decision, not a conversion.
• From a screenshot: it is device pixels. Divide by the screen's device pixel ratio to get CSS px.

From CSS pixels, a rem value is one division by the root size away.

Questions About pt and px

How many pixels is 12pt?

In CSS, 12pt is exactly 16px, because CSS defines 72pt and 96px as the same inch. In Photoshop, 12pt type is 12 pixels in a 72 ppi document and 50 pixels in a 300 ppi document. In a Windows app, a 12-point font is 16 pixels at 100 percent display scaling and 20 at 125 percent.

Is 1pt bigger than 1px?

Yes, in CSS. One point is 4/3 of a pixel, about 1.33px, so a 10pt font is larger than a 10px font. Going the other way, 1px is exactly 0.75pt.

Why do some converters say 12pt equals 12px?

They assume 72 pixels per inch, an old screen convention that CSS does not use. CSS fixes one inch at 96px, so 12pt is 16px in any browser. The 72 figure is only correct inside an image editor whose document resolution is set to 72 ppi.

Should I use pt or px for web fonts?

Neither, for body text. Both are absolute units that ignore the reader's font-size preference, so convert print sizes to rem instead: divide the point size by 12 to get rem at the default 16px root. Points are a good fit for print stylesheets, where the output is paper.

Are iOS points the same as CSS points?

No. An iOS point is a logical unit that the screen's scale factor turns into 1, 2 or 3 device pixels in each direction, much as a CSS pixel works. A size from an iOS spec usually carries to the web as the same number of CSS pixels, not multiplied by 4/3.

What is 12pt in rem?

1rem, at the default 16px root. Any point size divided by 12 gives its rem value at that root: 9pt is 0.75rem, 18pt is 1.5rem and 24pt is 2rem.

Sources

All sources checked on November 13, 2026. The conversion tables, the 12pt-across-contexts table, the rounding percentages and the worked print-to-rem set are our own arithmetic from the definitions below, computed with exact fractions in a script run for this guide.

• W3C, CSS Values and Units Module Level 4 (Working Draft, 12 March 2024), section 6.2 Absolute Lengths: 1in = 2.54cm = 96px, 1pt = 1/72 of 1in, 1px = 1/96 of 1in, pica definition, "mainly useful when the output environment is known".
• W3C, CSS 2.2, section 4.3.2 Lengths: reference pixel definition, 0.0213 degrees at 28 inches, about 0.26 mm, physical-unit anchor for print and pixel anchor for low-resolution devices.
• MDN Web Docs, CSS length (last modified July 8, 2026): unit definitions, 1in = 96px = 72pt, physical units not matching on low-dpi devices, device pixels per CSS pixel, note that absolute lengths do not follow user font settings.
• Microsoft Learn, DPI and device-independent pixels (last updated May 24, 2023): 1pt = 1/72 inch, logical inch of 96 pixels, 12-point font as 16 pixels, standard settings of 96, 120 and 144 DPI.
• Adobe, Format characters in Photoshop (last updated November 26, 2024): points as the default type unit, PostScript point as 1/72 inch in a 72 ppi image, PostScript (72) and Traditional (72.27) point options, Units and Rulers preference.
• Apple Developer Documentation, UIScreen scale: points as the logical coordinate space, scale factors 1.0, 2.0 and 3.0.
• Apple, Human Interface Guidelines: Typography (change log last entry December 16, 2025): iOS and iPadOS default text size 17 pt, minimum 11 pt.
• Android Developers, Support different pixel densities (last updated October 23, 2026): dp definition and 160 dpi baseline, px = dp x (dpi / 160), sp follows the user's text size, density buckets ldpi to xxxhdpi.
• Apple, Human Interface Guidelines: Accessibility: control size table, 44x44 pt default and 28x28 pt minimum on iOS and iPadOS.
• Android Developers, Make apps more accessible (last updated November 10, 2026): touch targets of at least 48dp by 48dp.

Maintained by the Lucky Graphics editorial team.