ASCII, Block and Emoji Widths
Recorded Canvas advance widths for four font requests in Chrome on Windows, with raw measurements and explicit fallback limitations.
Original measurements recorded 8 November 2026. This is a bounded experiment, not a survey of users or a market statistic.
Equal character counts do not establish equal widths
The table compares all 95 printable ASCII characters with a full block and a smiling-face emoji. Values are recorded advance widths at 16px, rounded to two decimals only for display. The source dataset retains the unrounded measurements for every tested character and the same character repeated eight times.
| Requested font | ASCII minimum | ASCII maximum | Full block U+2588 | Emoji U+1F600 |
|---|---|---|---|---|
| monospace | 8.80 | 8.80 | 8.80 | 21.97 |
| Consolas | 8.80 | 8.80 | 8.80 | 21.97 |
| Courier New | 9.60 | 9.60 | 9.60 | 21.97 |
| Arial | 3.05 | 16.24 | 11.34 | 21.97 |
In this recorded run, the Consolas and Courier New requests gave every tested printable ASCII character the same advance width. Arial did not. That is evidence for those requests in this environment, not proof that every Unicode symbol shares their spacing. Compare the block and emoji columns before assuming that a monospace setting makes mixed-symbol art align.
What the full dataset covers
Each of the 4 font requests was tested on U+0020 through U+007E, all 32 characters from U+2580 through U+259F, three selected Braille patterns, U+1F600, the woman-technologist sequence and e followed by U+0301. This is a declared test corpus, not all Unicode characters. The JSON lists every sequence, its code points, UTF-16 length, UTF-8 byte count, single advance and eight-repeat advance.
Inspect the actual characters in your text when tabs, combining marks or invisible characters may be involved. That inspector reveals code points; it is not a terminal-cell or pixel-width calculator. For a visual specimen, see the existing live font rulers.
Method and what this does not prove
Recorded at , with browser-reported user agent Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/152.0.0.0 Safari/537.36 and platform Win32. The capture loads no web fonts. We set a Canvas context to 16px for each requested family and disabled font kerning. The generic monospace keyword was unquoted; named families were quoted.TextMetrics.width defines the measured quantity as advance width in CSS pixels.
The browser can substitute a fallback font for some or all glyphs. We recorded the requested Canvas font string, but did not identify the resolved physical fonts, audit installed font versions or verify glyph shapes. An equal advance does not prove that a glyph is present, readable or visually joins its neighbors. Nor does this measure line wrapping, ANSI escape handling, grapheme segmentation or terminal cell allocation.
Unicode's East Asian Width annex describes narrow, wide and context-dependent classifications. It is not a universal browser pixel-width lookup. Do not convert these CSS-pixel measurements into terminal-cell guarantees. Different operating systems, font installations, sizes and rendering engines need their own test.
Download the measurement source, the local capture page template and the compiled module. The template can be saved as capture.html alongside the module and source fixtures, then served on localhost with the same /research/2026-11-08/ path. It runs locally and offers a JSON download; it sends no measurements to a server.
Use these findings as a diagnostic, not a compatibility badge
Check your actual destination with the exact text and font. If the grid is already correct and you need to preserve its appearance, export supported text to PNG. That preserves a rendered result, not a promise of equal cell widths in somebody else's terminal.