Most sizing advice treats pica type size as one number you memorize and move on. Twelve points, one pica, sixteen pixels, job done. That shortcut fails as soon as a print archive, a desktop file, and a browser all carry the same label and produce different physical results.
A pica measures space. It doesn't measure the letter you see. Two faces set at the same nominal size can look nothing alike, and a file marked "12 pt" may have been built on a historical American pica rather than the pica your design app uses today.
Designers, developers, agencies, and compliance teams need the conversion first, then a written note of which system produced it, then a separate note of what the screen drew. Nothing in this guide is legal advice. A correct size still doesn't license a font.
Pica Type Size Conversions at a Glance
Start with the relationships you'll type. Under the PostScript convention used in modern desktop publishing, 1 pica is exactly 1/6 inch (about 4.233 mm) and 1 point is 1/72 inch. CSS uses a reference density of 96 pixels per inch, so 1 point is 1.333 px and 1 pica is 16 px.
| Unit | Equals | CSS pixels |
|---|---|---|
| 1 pica | 12 points | 16 px |
| 1 point | 1/72 inch | 1.333 px |
| 6 picas | 1 inch | 96 px |
| 18 picas | 3 inches | 288 px |
| 30 picas | 5 inches | 480 px |
| 72 points | 1 inch | 96 px |
A column of 18 picas. Six picas make an inch, so 18 picas are 3 inches. At 16 px per pica, that column is 288 CSS pixels wide. You're measuring the column, not the cap height inside it.
A margin of 30 picas. That measure is 5 inches, or 480 CSS pixels. A 72-point measure is 6 picas, which is 1 inch and 96 CSS pixels. These are the column and margin widths that show up in print files.
Every row is a linear measurement. It describes space on a page or in a layout box. It doesn't describe the visible height of a lowercase letter. Historically, "pica type" meant type with a 12-point body. The printed lowercase letters sit inside that body, and they change with the typeface.
Before you convert a value, write down which pica the source file uses. The Wikipedia entry on typographic units records that in 1886 the United States Type Founders' Association adopted the American Point System. Under that Johnson pica, 1 pica equals exactly 0.166 inches (about 4.216 mm), and 1 point is about 0.351 mm. Later digital systems adopted a PostScript pica of exactly 1/6 inch, 4.233 mm. Archives, desktop files, and web conversions can share a nominal size and still disagree.
If you're checking what a nominal 12-point setting means once it leaves the page, the note on what 12 pt means for print and screens keeps the label and the rendered result apart.
Practical rule: A number without a system is not a measurement.
Where the Pica Came From and Why Versions Differ
A 1960s brochure's column specifications can break when rebuilt in a current design file. The word pica spans several measurement systems, and each assigns a slightly different length to the unit.
Four dates that changed the ruler
1737. Pierre Simon Fournier introduced a successful point-based sizing system, giving designers a named size instead of relying on each foundry's practice. French typography later used the Didot system. The type-size reference at Sizes.com describes a French pica, or cicero, as 12 Didot points, measuring about 4.512 mm. That made it wider than the pica used in later American shops.
1886. The United States formally standardized its point system. The Johnson pica replaced the slightly different picas individual foundries had produced. Printers working within that system could use a shared body size rather than relying on a shop-specific measure.
Desktop publishing. Digital typography adopted the PostScript convention: 1 pica equals exactly 1/6 inch, or about 4.23 mm, and 1 point equals 1/72 inch. Picas continued to describe page geometry, including column widths, margins, and grids. The word stayed the same while the millimetre shifted slightly.
CSS. Browsers map the unit using a 96 px-per-inch reference, so 1 pica equals 16 CSS pixels. That conversion defines a digital layout measurement; it does not guarantee a physical size on every display.
| Pica system | Pica (mm) | Point (mm) |
|---|---|---|
| American (Johnson) pica | 4.216 | 0.351 |
| PostScript pica | 4.233 | 0.353 |
| Didot cicero | 4.512 | 0.376 |
Why a fraction of a millimetre still matters
The American and PostScript picas differ by about 0.017 mm. Across a 60-pica measure, the difference adds up to about 1 mm. A Didot cicero is about 0.30 mm longer than an American pica. Across a grid of columns, margins, and gutters, small differences can shift the layout.
When rebuilding an older brochure, check which pica system its specifications use before entering the numbers in a current file. Two files can show the same label while producing different physical widths, especially when the measurement system and rendering environment differ.
Record the system alongside the value: “30 picas, PostScript” identifies a measurement more clearly than “30 picas.”
Why a 12-Point Pica Is Not a 12-Point Letter
Think of a pica the way you'd think of a shelf. The shelf has a width. The objects on it have their own height, and two objects of the "same size" can still look unlike if one is tall and narrow and the other is short and wide.
Point size describes the em square, the design box the font was drawn in. It doesn't describe cap height or x-height. A nominal 12-point or 1-pica setting doesn't guarantee the same visible letter height, the same line spacing, or the same page coverage from one face to the next.
Three ways the same size changes what you see
A large x-height reads bigger. Set a text face with a tall lowercase next to one with a small lowercase, both at 12 pt. The first looks closer to 13 or 14. Readers judge the lowercase, not the invisible em box.
Long ascenders and descenders change the page. Those strokes eat the gap between lines. The point size didn't move, but the paragraph looks denser, and you often have to open the leading so the lines don't collide.
Narrow letters fill a column differently. In a 30-pica measure, a condensed face fits more characters than a wide one. Line length in characters shifts even though the pica width is identical. That's a reading change, not a conversion error.
The Wikipedia article on the typographic point) is clear that CSS maps 12 pt to 16 px from a 96-pixels-per-inch assumption, while the modern de facto pica is about 4.23 mm. That mapping is a fixed digital relationship. It isn't a guarantee of physical size on every display.
What moves perception while the label stays put
- Typeface choice: x-height, cap height, and stroke contrast change apparent size at one declared point size.
- Font substitution: a missing licensed face falls back to another family, and the em square stays while the drawing changes.
- Browser zoom and device pixel density: the CSS pixel is scaled to the hardware, so 16 px isn't one physical length on every screen.
- User text settings: a reader who enlarges text overrides the size you shipped.
A unit measures space, while readability is a property of the face, the line, and the context.
Teams move type between design files, CSS, PDFs, and brand systems. Nominal sizes stay identical while visual and physical results change. A useful report shows declared size, computed CSS size, fallback font, rendered context, and physical-size assumptions as separate fields. It doesn't stamp a face "12pt" or "1pc" and stop. How those sizes stack into a typography hierarchy that works on every screen depends on that split, not on the conversion alone.
Convert a Pica Spec to CSS Without Drift
A clean handoff is a short procedure. Each step exists because the previous one can lie if you skip it.
- Identify the source. Open the PDF, the layout file, the legacy document, or the brand guide, and name the pica system using the comparison of American, PostScript, and Didot lengths. You're stopping a historical pica from being treated as a PostScript pica before any arithmetic starts.
- Convert picas to points. Multiply by 12, because one pica is twelve points. An 18-pica column is 216 points. Do this before pixels so you can check the spec in the unit the print file uses.
- Convert points to CSS pixels. Multiply by 1.333. The Adobe type resources FAQ states the CSS reference result directly: 1 pt = 1.3333 CSS px, 12 pt = 16 CSS px, and 1 pica = 16 CSS px, because CSS uses 96 pixels per inch against 72 points per inch. The common slip is treating 12 pt as 12 px, which makes the text 25% smaller than the common 16 px browser baseline.
- Move to rem for responsive layouts. Divide the pixel value by the root font size, usually 16 px, so 12 pt becomes 1 rem. A fixed pixel lock fights user resizing. Relative units let the root change without rewriting every heading.
- Set line-height yourself. Don't inherit it. Leading decides how the text sits, and font metrics already reserve space for ascenders, descenders, and line spacing, so the drawn letter stays smaller than its em box.
- Compare computed styles with the spec. In browser tools, read computed
font-sizeandline-height, then set them next to the original points or picas. Note rounding and zoom. A 16 px declaration that computes to something else is drift, not a typeface quirk.
1pc in CSS preserves typographic intent when you want the pica named outright. Responsive interfaces usually sit better on rem plus an explicit line-height. For type that should scale between breakpoints without a pile of media queries, CSS clamp for responsive text from VeloCMS shows how a fluid size can sit between a floor and a ceiling.
A 16 px glyph doesn't physically measure 4.233 mm on every screen. Browsers map CSS pixels to device pixels through viewport and display scaling. The practical check is still the same: inspect declared units, then rendered geometry.
A correct conversion looks boring. Computed values match the spec within rounding. Line-height is explicit. At 200 percent zoom, type reflows without a clipped heading or a column that won't scroll. If you want the surrounding decisions on measure, hierarchy, and code, the practical guide to website typography picks up from the unit and into the page.
Font Licenses Limit Pica-Sized Text Online
A 1-pica setting describes the text's size, not the rights to use its font files. Licensing depends on how and where those files are used, so the same typeface may be covered for a printed document but require different rights when served on a website.
Desktop license. This generally covers installing fonts on specified users' computers for applications such as Adobe software or Microsoft Word, and using them in static designs, print, logos, and some PDFs. Monotype's licensing guidance bases desktop licensing on the number of users. Abbreviated Foundry's desktop license is framed around licensed computing units and describes desktop fonts as intended for non-dynamic documents such as books, newspapers, logos, and visual identities.
Web license. Hosting font files and serving them through CSS @font-face can require web rights. Monotype's web licensing terms describe licensing that can be annual, limited to a single domain, and measured by page views. A license for one website does not automatically cover other sites. Check the EULA for domains, users, traffic tier, embedding rules, and permitted file formats before deployment.
For example, a team may have the desktop seats needed to create a printed brand guide with body text set at 1 pica. Uploading those same font files to a client's site may require web rights. Sharing the files with a contractor can also exceed the license if that person is not covered.
The resulting problem is a rights issue, not a pica-conversion error. A foundry may require the team to stop using the font, leaving it to replace the typeface and rebuild affected layouts.
Font Checker Pro does not license typefaces to customers. Identifying a typeface in an audit report does not grant permission to use it. Read the applicable license or consult qualified counsel, and see this guide to font licensing for websites for more on how web rights differ from desktop coverage.
Confirm Pica Specs and Licenses Before Handoff
Don't send files until the pica values and the font licenses both check out. A beautiful conversion that's attached to the wrong license is still a bad handoff.
Work through this before the files leave the team:
- Convert, then compare. Turn pica specs into points and CSS pixels with the conversion table, and read computed sizes in the browser against the spec.
- Match every file to a right. Pair each font in the design or on the site with a desktop license or a web license, not with a guess based on the family name.
- Keep the paperwork with the files. Store invoices, EULAs, named users, domains, traffic tier, and renewal dates where the next person can find them.
- Set a rescan date. Run it again after a redesign or a new domain, because the live page drifts from the file you approved.
Hand inspection is enough for one small page with simple terms. It slows down on a large site that several teams share. Our crawler opens every subpath, extracts fonts, and fingerprints visuals, with an average sweep of about 4.2 seconds. The Drift audit crawls subpages and flags rogue typefaces the team didn't ship, so you can compare what's served with the license records you stored. Scheduling that rescan belongs next to the licensing differences between web and desktop fonts, because a new domain can invalidate a web tier that was fine last quarter.
Check by hand when the scope is small and the terms are simple. Automate when the site is large or shared. Licensing calls should still go to qualified legal counsel. A report organizes evidence. It doesn't replace the EULA.
Font Checker Pro scans a live URL, a PDF, an image, or a zipped font set and reports the typefaces in use, separate from the pica or point size written in the spec. Use it to see declared type against what's served, including faces nobody meant to ship, before a handoff. Visit Font Checker Pro and run the page you're about to send.
