PX to PT Converter
This PX to PT Converter is a lightweight browser tool that instantly converts between pixels and points for screen and print workflows.
Key features:
- Bidirectional conversion - type in either field and the other updates in real time
- DPI mode toggle - switch between Screen (96 dpi) and Print (72 dpi) to match your context
- Live formula display - shows the exact multiplication used so you understand the math, not just the result
- Common values reference - 12 clickable chips for frequently used sizes like 8px, 16px, 24px, 64px
- Copy buttons - grab either value to clipboard with one click
- Swap - flip the direction of conversion without retyping
Useful for designers moving between Figma, CSS, and print documents. The formula bar makes it a learning tool too, not just a calculator.
How to Use This PX to PT Converter
Pick Screen (96 dpi) or Print (72 dpi) at the top of the converter above, then type a value in either field. The other field updates as you type, and the formula bar shows the exact multiplication behind the result.
The 12 chips under the fields fill in common sizes with one click. Use the swap button to flip direction, and the copy buttons to grab either value.
The DPI toggle matters because pixels and points only line up at 72 dpi. At the 96 dpi standard most screens and every browser use, 1px equals 0.75pt. That's why assuming 1px = 1pt breaks things in production.
The PX to PT Formula
The general formula depends on the pixel density of the output environment:
pt = px × 72 ÷ PPI
PPI is the variable most people forget. At the 96 PPI web standard, 72 ÷ 96 works out to 0.75, which gives the shortcut every converter and every CSS print stylesheet relies on:
pt = px × 0.75
- 16px → 12pt
- 24px → 18pt
- 32px → 24pt
- 10px → 7.5pt
The W3C's CSS Values and Units Module fixes that ratio directly: one CSS pixel equals 1/96 of an inch, and one point equals 1/72 of an inch. That 1/96 figure is the same one used to work out how many pixels fit in an inch on a standard display.
At 72 PPI, pixels and points are equal: 1px = 1pt. This is where the "they're the same" myth comes from. It only holds at 72 PPI, which is rare on modern screens.
Rounding matters here. Values that don't divide evenly produce long decimals, and most design tools round to one or two decimal places rather than showing the full number. A designer setting 10px gets exactly 7.5pt, but 15px lands on 11.25pt.
PT to PX: The Reverse Formula
Going from points back to pixels at 96 PPI, divide by 0.75 or multiply by 1.333:
px = pt ÷ 0.75
- 12pt → 16px
- 9pt → 12px
- 18pt → 24px
- 11pt (Word's default) → 14.67px
The relationship is fixed and symmetrical, since both units trace back to the same inch. Type a value in the Points field of the converter above to run it.
PX to PT Conversion Chart
Reference values at 96 PPI:
| PX | PT |
|---|---|
| 8px | 6pt |
| 10px | 7.5pt |
| 12px | 9pt |
| 14px | 10.5pt |
| 16px | 12pt |
| 18px | 13.5pt |
| 24px | 18pt |
| 32px | 24pt |
| 48px | 36pt |
| 64px | 48pt |
| 72px | 54pt |
| 96px | 72pt |
Standard body text sits at 16px / 12pt. That pairing matters because 16px is the default font size every major browser renders under the CSS medium keyword. Headings and display sizes scale up predictably from there.
Need the pixel value in a different physical unit instead? A dedicated pixel to inches conversion tool handles that on its own, and a similar pixel to centimeter converter covers the metric side.
What Is a PX to PT Converter?
A PX to PT Converter is a calculator that turns pixel values into point values for typography, print layouts, and design software.
It exists because CSS renders text on screen in pixels, while print and page layout tools measure text and spacing in points. Without a fixed conversion, a font that looks right on screen can print at the wrong size entirely.
Designers reach for a PX to PT Converter in a few recurring situations:
- Exporting a web mockup into a print-ready PDF
- Setting font sizes for a document meant to be printed, not viewed on screen
- Matching typography specs between a web team and a print team
- Translating CSS font sizes into point values for a style guide
The tool differs from a general unit converter because it assumes a typography context, not a plain physical measurement one. Feeding it a pixel value meant for inches or centimeters gives a technically correct but practically useless answer, since those units don't carry the print heritage that points do.
Adobe's PostScript Language Reference Manual fixed the point at exactly 1/72 of an inch in 1985, replacing the slightly smaller 1/72.27-inch printer's point that had governed type since 1886. That single decision is why a modern px to pt conversion produces one consistent, predictable number instead of the fractional point sizes older print shops had to work around.
PX vs PT: What Sets These Units Apart
Pixels and points come from two different measurement traditions, and that's the entire reason a converter is necessary.
A pixel is tied to the screen, a point is tied to the printed page, and neither one adjusts to match the other automatically.
What Is a Pixel (PX)?
Pixel is short for picture element, the smallest unit a screen can render. Pixels are screen-dependent: a 16px font on a 96 PPI monitor looks different from 16px on a 72 PPI display.
- A CSS pixel is a fixed reference unit, not the same thing as a physical dot on a monitor
- Its rendered size shifts depending on the screen it's displayed on
- High-density displays pack more physical dots into the space of one CSS pixel
Apple's Retina displays are the clearest example of this pixel density effect, doubling the physical dot count so one CSS pixel spans two device pixels in each direction.
What Is a Point (PT)?
Point is a typographic unit that predates computer screens by centuries, used in printing and typesetting.
One point equals 1/72 of an inch, a fixed physical measurement that doesn't change based on device or display.
Twelve points make one pica, another typography unit that shows up in page layout software far more than it does on the web.
Because points are anchored to a physical inch, the same point value prints at the same size no matter which printer or software produced the file.
Why DPI Changes the PX to PT Conversion
DPI decides how many physical dots represent one inch, and the 0.75 ratio only holds at the 96 DPI standard built into CSS.
Change the DPI, and the same pixel count no longer equals the same physical size.
Commercial printers generally require 300 DPI for sharp output, compared to the 72 to 96 DPI most screens render at. Vistaprint's upload guidelines, for example, set 300 DPI at final print size as the minimum.
| DPI Standard | Typical Use | Effect on PX to PT |
|---|---|---|
| 72 DPI | Legacy screen and early Mac displays | 1px = 1pt |
| 96 DPI | Modern web browsers, CSS default | 1px = 0.75pt, the standard ratio |
| 300 DPI | Professional print production | 1px = 0.24pt; ratio must be recalculated |
A pixel-to-point conversion built for screen use looks correct in a browser but comes out undersized once it hits a 300 DPI print run.
When to Use PX vs PT in Design Work
Screen work calls for px, print work calls for pt, and mixing the two inside one workflow creates sizing headaches.
Pixels (px):
- Matches device screens and viewports exactly
- Ignores physical size, so a layout that looks right on screen can print far smaller or larger than expected
Points (pt):
- Holds a fixed physical size on paper no matter which device opened the file
- Doesn't map cleanly onto pixel-based screen grids, so on-screen previews can look slightly off
Many design teams standardize spacing using an 8-point grid system, which keeps every measurement in px while still scaling cleanly once it's converted for print.
That works because multiples of 8px convert into round point values without leftover decimals.
Screen-first teams building for multiple devices tend to lean on responsive design practices, where px still anchors most measurements even as layouts adapt to different screens.
PX vs PT vs EM vs REM: Choosing the Right CSS Unit
Pt rarely shows up in day-to-day CSS, since browsers default to px, em, and rem for on-screen sizing.
Its main role in CSS is print stylesheets, where a fixed physical unit matters more than a scalable one.
The W3C's WCAG 1.4.4 guideline requires that text can be resized up to 200% without losing content or function. That is a bar fixed units like px and pt struggle to clear on their own.
| Unit | Type | Scales With | Typical Use |
|---|---|---|---|
| px | Absolute | Nothing, fixed size | Screen layouts, borders |
| pt | Absolute | Nothing, fixed size | Print stylesheets, typesetting |
| em | Relative | Parent element's font size | Component-level sizing |
| rem | Relative | Root element's font size | Global font and spacing scale |
The difference between em and rem trips up a lot of newcomers, since both scale relative to a font size but reference different elements.
Guidelines for web accessibility generally favor rem and em over px or pt for text, since relative units respect a user's browser settings.
Pt keeps its place for print-specific stylesheets, but it stays a minor player everywhere else in CSS.
Which Software Uses PT vs PX by Default
Browsers and screen-based tools default to px, while print and word-processing software defaults to pt.
The split lines up with what each program was built to output.
| Software | Default Unit | Built For |
|---|---|---|
| Web browsers / CSS | px | Screen rendering |
| Adobe InDesign | Picas and points | Print layout |
| Microsoft Word | Points | Documents, printing |
| Figma | px only | Screen and UI design |
InDesign ships with picas as the default ruler unit for new print documents, though type size itself is always set in points, as Adobe's measurement units documentation lays out.
Word handles this even more directly: its Font.Size property returns and sets font size in points, and a blank document defaults to 11-point Calibri.
Figma sits at the other end entirely. Figma's own documentation shows every dimension field in pixels, with no point option built into the interface at all.
That gap causes real friction when a type spec written in points for print gets handed to a team working in a pixel-only tool. Someone has to convert it in one direction and back.
Rendering differences compound the problem across programs, which is part of why cross-browser compatibility testing matters for any layout that mixes both unit types.
How to Convert PX to PT in CSS
Converting inside CSS itself takes four steps.
- Identify the pixel value you're working from
- Multiply that value by 0.75
- Write the result as a pt value in the property that needs it, such as font-size
- Preview the page and confirm the rendered size matches what you expected
A 20px heading becomes font-size: 15pt; once converted.
Most teams only do this when writing a dedicated print stylesheet, since pt inside a normal screen stylesheet doesn't behave the way px does.
Wrapping the pt-based rules inside a print-specific media query keeps them from affecting how the page looks on a regular screen.
Skipping that step means visitors browsing normally could see fonts sized for paper, not monitors.
How to Convert PX to PT in Design and Print Software
Converting in Adobe Illustrator and InDesign
- Open Preferences and set the ruler or type unit to points
- Enter the pixel-based measurement multiplied by 0.75 directly into the size field
- Confirm the value in the Character or Paragraph panel, both of which display type size in points by default
Both applications keep type measurements in points regardless of what the ruler units are set to, since points are the native typography unit in Adobe's print tools.
Converting in Microsoft Word
- Font size field: already measured in points, so a converted pt value goes straight into the size box
- Spacing and margins: Word defaults to inches for page layout, which needs a separate conversion if pixel values are involved
There's no direct px input anywhere in Word's interface, so every pixel-based spec has to be converted before it's usable.
Converting a Screen Design File for Print
Exporting a screen mockup into something printable means changing more than just the font sizes.
The whole file typically needs to move to a much higher screen resolution equivalent before pixel-based measurements translate into anything usable on paper.
Three things change at once during that export:
- Font sizes convert from px to pt using the 0.75 ratio
- Image resolution shifts from screen density up toward 300 DPI
- Spacing and margins often get rebuilt in inches or millimeters rather than scaled directly
Skipping any one of those three steps is the most common reason a screen-perfect design comes back from the printer looking wrong.
When PX to PT Conversion Does Not Apply
The 0.75 ratio only holds at exactly 96 DPI.
Move outside that specific condition, and the standard px to pt formula stops giving a physically accurate answer.
Where the standard formula breaks down:
- Any screen or document set to a DPI other than 96, since the ratio was fixed to that one baseline
- High-density Retina and mobile displays, where one CSS pixel maps to two, three, or more physical device pixels
- Files converted for 300 DPI print output without recalculating the ratio for that resolution
- Documents using Didot points instead of standard points, since the two point systems aren't the same physical size
The W3C's own reference pixel definition acknowledges the gap directly: a CSS pixel is roughly 0.26mm at a normal reading distance. That figure assumes a specific viewing setup rather than an actual measured screen dot.
It's a deliberate approximation, not a physical guarantee, which is exactly why the same pixel count looks like different physical sizes on different screens.
A few mistakes show up constantly because of this:
- Applying the 0.75 ratio to a print file that's actually set to 300 DPI, producing text far smaller than intended
- Treating a pica and a point as interchangeable, when a pica is actually twelve points
- Assuming a converted pt value will look identical across every browser or every operating system's rendering engine
When any of these conditions apply, the fix isn't a different formula. It's switching to whatever unit the destination software actually measures in, whether that's DPI-aware print settings or software-native point fields.
Static units like px and pt also complicate things for readers who resize text in their browser. That is one more reason guidance on accessible typography steers away from fixed units for on-screen body text entirely.
FAQ on PX To PT Converter
What Is a Pica and How Does It Relate to Points?
A pica is a typographic unit equal to twelve points, used mainly for measuring column widths and line lengths in print layout.
Points measure type size, picas measure larger blocks of space. Adobe InDesign's ruler displays both as p and pt notation.
Does Browser Zoom or Screen Density Affect the Conversion?
Browser zoom scales the whole page, pixels included, so the 0.75 ratio still holds at any zoom level.
Screen density works differently: high-density displays pack more physical dots into each CSS pixel, distorting how a converted point size looks without changing the math.
Can You Convert PT Back to PX Using the Same Formula in Reverse?
Yes. Divide the point value by 0.75, or multiply it by 1.333, to get pixels back. 12pt becomes 16px, 18pt becomes 24px. Worked examples are in the PT to PX section above.
What Is the Difference Between a Standard Point and a Didot Point?
A standard point, used in CSS and most software, equals 1/72 inch, or about 0.353mm.
A Didot point, common in continental European typesetting, measures roughly 0.376mm, based on the old French Royal inch rather than the modern inch.
Do Relative Units Like REM and EM Need Conversion to PT at All?
No. Rem and em scale relative to a font size, while pt is a fixed physical unit with no relationship to a parent or root element.
Converting between them defeats the purpose of using a relative unit in the first place.
How Do You Confirm a PX to PT Converter Result Before Using It?
A PX to PT Converter result gets confirmed by checking three things in order: the DPI assumption behind the number, the unit the destination software expects, and how the value actually renders once placed.
Skipping the order costs more time than following it. A wrong DPI assumption only surfaces on the third check, after effort has already gone into the first two.
- Confirm the DPI the file is built for
- Match the unit to the destination software
- Render or print a test sample before finalizing
Following this sequence adds one manual step to every handoff between a screen team and a print team. In exchange, the document never needs resizing after delivery.
Once font sizes check out, the next place inconsistency hides is spacing and layout width. That is where comparing px against rem becomes the more useful conversion question.