The missing space between 日本語 and English, and the CSS that adds it

Set Chinese or Japanese text next to Latin words or Western numerals and the two runs collide. Typesetting convention puts a thin space between them. CSS can now insert it, and the declaration that works in all three engines is this one:

:root {
  text-autospace: normal;
}

text-autospace is inherited, so setting it once at the root is enough.

The reason you have to write it at all — when the specification says normal is the initial value, and normal is defined as spacing turned on — is the most useful thing to know about this property. Every shipping engine disagrees with the spec here, and in the same direction.

What the property does

CSS Text Module Level 4 defines text-autospace as controlling "spacing between adjacent characters on the same line within the same inline formatting context using a set of character-class-based rules".

The values:

The amount is specified: one eighth of the CJK advance measure, or 0.125ic. The spec explains the choice in a note — conventions "typically range from 1/4ic to as low as 1/8ic, with 1/4ic being more common in historical contexts due to metal type limitations and 1/6ic or thinner being more common in proportional typesetting" — and CSS picked the thin end "in order to be conservative in its interference".

Crucially, the space is a rendering effect only. The property "has no effect on the underlying content, and must not affect the content of a plain text copy & paste operation". Someone copying a product code out of your page gets the code, not the code plus a space. That alone makes it better than the old workaround of wrapping Latin runs in spans with margins.

Every engine ships the wrong initial value

The spec says Initial: normal. Browsers do not.

browser-compat-data carries the same note on every single engine that supports the property: "the initial value is no-autospace instead of normal". The divergence is tracked in CSS Working Group issue #12386, opened in June 2025, which asks the group to reconsider the initial value now that browsers have shipped the other one.

So the behaviour you get today is: nothing, unless you ask.

/* Does nothing — this is already the effective default everywhere */
.article { text-autospace: no-autospace; }

/* Turns the spacing on */
.article { text-autospace: normal; }

If the working group settles on no-autospace, text-autospace: normal is what you will keep writing. If it settles on normal, the declaration becomes redundant but harmless. Either way, writing it explicitly is the stable choice — and normal is the only value with support in all three engines.

The keyword support matrix is not uniform

This is the second trap. The property is supported more widely than its interesting values.

At the time of writing, from browser-compat-data:

Chromium implements exactly two keywords. Writing text-autospace: ideograph-alpha gives you spacing in Firefox and Safari and an invalid declaration in Chrome — which, because it is invalid, falls back to the effective default of no spacing at all.

The practical rule: use normal. It means ideograph-alpha ideograph-numeric by definition, and it is the only spelling every engine parses. Reach for the individual keywords only when you specifically want one and not the other, and accept that Chrome will do nothing.

Counting only normal and no-autospace, the property reached all three engines on 11 November 2025, which is the Baseline date web-features records for it. The feature as a whole is still marked as not Baseline, precisely because of the rows above.

Why it does nothing in your layout

The spacing is only inserted where the two character runs are "directly adjoining on a line, i.e. without any intervening non-zero margin, border, or padding or intervening characters (such as a quotation mark or a space)".

That sentence rules out several extremely common markup patterns.

A wrapper with padding or a margin. The habit of wrapping Latin runs for font control is the exact thing that suppresses the automatic spacing:

<!-- No automatic space: the padding sits between the runs -->
<p>使用 <span style="padding: 0 .1em">Figma</span> 制作</p>

<!-- Automatic space applies -->
<p>使用 <span style="font-family: Inter">Figma</span> 制作</p>

A span with no box properties is fine — the spec says that at element boundaries the extra spacing is rendered within the innermost element containing the boundary, so crossing an element boundary is not itself a problem. Non-zero margin, border or padding is.

An intervening character. A quotation mark, a bracket or an existing space between the two runs means they are not adjoining, so nothing is inserted. That is usually what you want: 「日本語」 does not need extra air around the brackets.

Content that already has manual spaces. Plenty of CJK web copy carries literal spaces around Latin words, because until recently that was the only way to get any. text-autospace will not double them — the default insert behaviour only adds a space "if there are no space characters of any kind already there". But it also will not normalise them to the correct thin space. The value that would, replace, removes the existing U+0020 and inserts proper spacing instead, and no engine supports it yet.

For existing content, that leaves two honest options: leave the manual spaces alone and accept a full space where a thin one belongs, or strip them at the content layer and let CSS do the spacing from then on.

It stacks with your other spacing

text-autospace is additive with word-spacing and letter-spacing. Whatever those contribute is added to the 0.125ic the property inserts.

That matters for display type. A heading with letter-spacing: 0.05em and text-autospace: normal gets both at the ideograph–Latin boundary, which can read as a gap rather than a join. Tight tracking on mixed-script headings is worth a look at real sizes.

The other half: text-spacing-trim

text-autospace handles the space between scripts. The complementary problem — full-width CJK punctuation carrying its own whitespace inside the glyph, so a line starting with 「 looks indented — is text-spacing-trim's job.

That property is in a worse state: Chrome and Edge have had it since 123, Firefox has an open implementation bug, and Safari has not shipped it. So the two halves of good CJK typography currently have almost inverted support, and neither is safe to depend on for layout. Use both as enhancements, and do not let either one carry a design that breaks without it.

What to actually ship

The declaration at the top of this page, at the root, inherited everywhere. It is a real improvement for readers of mixed CJK and Latin text, it degrades to today's rendering in any browser that does not support it, and it changes nothing on a page with no ideographs in it.

Do not wrap it in @supports. A browser that does not understand the value drops the declaration, which is exactly the fallback you want.

Sources

• CSS Text Module Level 4, the text-autospace property — CSS Working Group editor's draft, for the values, the 0.125ic amount and the adjoining rules
• CSS Text Module Level 4, inter-script spacing — the definitions of ideographs, non-ideographic letters and numerals
• csswg-drafts issue #12386 — reconsidering the initial value
• @mdn/browser-compat-data — per-value support and the initial-value note
• web-features — Baseline status and dates