Paragraph Width Optimizer
Measure
Reference table
| Characters | Verdict | Typical use |
|---|---|---|
| < 30 | very narrow | mobile UI labels, sidebars; hyphenation essential |
| 30–44 | narrow | mobile body copy, multi-column print |
| 45–75 | comfortable | the standard reading band for body text |
| 76–90 | wide | needs more leading and a shorter measure on narrow screens |
| > 90 | very wide | only for large display text, never for reading |
Preview at the measured measure
A measure of 45 to 75 characters is the band where the eye can return from the end of a line without losing its place. Below it the reader's rhythm breaks on every line; above it the return sweep becomes a search.
.measure {
font-family: 'Lora', serif;
font-size: 1.1250rem;
line-height: 1.6;
max-width: 594px; /* 33em · ≈ 0 characters */
/**
* ch is the width of "0" — close enough for a first pass, but measure the
* real sample when the face has unusual digit widths.
*/
}Why not just count characters?
Counting characters assumes an average width, and the average differs by face: a condensed face fits ~25% more characters in the same box than a wide one at the same size. Measuring the real sample in the real face at the real size is the only way the number means anything — which is what this tool does.
You Might Also Need
The paragraph width optimizer measures the real measure — the characters per line a column actually produces — by measuring the sample text with the Canvas API instead of assuming an average glyph width. Counting characters in the abstract is the error it exists to avoid.
What is Paragraph Width Optimizer?
The paragraph width optimizer answers one question with a measurement rather than an estimate: how many characters per line does this text, in this face, at this size, inside this container actually produce.
The measurement works by drawing the sample string to a canvas at the chosen size and face, reading its width, and dividing by the character count and the size to get an average glyph width in em. The container width divided by that average gives the characters per line, which is why the number changes when the face changes instead of staying fixed.
Four inputs are involved, and each one moves the answer.
- Face, chosen from the catalogue, because a condensed face fits roughly a quarter more characters into the same box than a wide one at the same size.
- Size, from 12 to 32 pixels, which scales the average glyph width directly.
- Container width, from 240 to 1600 pixels, which is the variable being optimised.
- Line height, from 1.1 to 2.4, which does not change the measure but decides whether a wide measure is comfortable.
The verdict bands are the part that translates the number into a decision. Under 30 characters a column is very narrow and needs hyphenation to avoid rivers; 30 to 44 suits mobile body copy and multi-column print; 45 to 75 is the standard reading band; 76 to 90 is wide and wants more leading; and beyond 90 characters only large display text survives, never running copy. The tool also reports the container width that would put the measure at 66 characters — the middle of the comfortable band — and an approximate line count for the text you pasted, derived from its length and the measured measure.
Several honest limits come with a measurement taken through the Canvas API, and they are worth stating before the number is quoted.
- The sample has to be real: measuring a placeholder string returns the average width of those characters rather than of your prose.
- The measurement uses the face and size selected in the tool, so a page that loads a different font at a different size will measure differently from the readout.
- The line count is an approximation rather than a layout, since it multiplies the text length by a factor instead of breaking lines.
- The Canvas API measures one run of text, so letter-spacing, word-spacing and any justification applied in the page are outside the calculation.
- Nothing measures the container itself, so a max-width that a grid or a flex rule overrides still has to be confirmed in the browser.
The output is a small rule — a max-width in pixels with its em and character equivalents in comments, plus the line height — which is the practical way to hold a measure in place while the container around it stays fluid. The rule belongs on the paragraph rather than on the page, which keeps the measure intact when a sidebar takes part of the row. Pair it with the leading the line height optimizer derives and the column stops being a guess at every breakpoint.
How to use Paragraph Width Optimizer
- Paste a real paragraph rather than a placeholder, since the average glyph width is measured from the characters you supply.
- Choose the face and size, then set the container width and watch the characters-per-line readout rather than judging the column by eye.
- Read the verdict against the band table and, if the measure is outside the comfortable band, jump to the ideal container width the tool reports.
- Copy the max-width rule and adjust the line height for the measure you settled on.
When to use Paragraph Width Optimizer vs related tools
Reach for it when a column is noticeably hard to read and the cause has not been diagnosed, when a design has to hold a measure across a fluid layout, or when a condensed face is being chosen and the extra characters per line it brings need to be quantified. Measuring rather than counting is the point. For the leading that pairs with the measure, the line height optimizer derives it from the character count; the CSS clamp calculator handles the fluid container, and the type scale generator supplies the font size the measure depends on.
Privacy & Security
This tool runs entirely in your browser — no data ever leaves your device. There is no server round-trip, no upload, no logging, and no account required. Your input is processed locally using client-side JavaScript and is never stored, transmitted, or accessible to anyone else. When you close the tab, everything disappears.