Japanese text that doesn't drift — measurement-based baseline correction for major fonts

Take a Japanese design built in XD, drop it into Figma, and you’ll often notice text drifting just a few pixels vertically — annoying when pixel-level layout actually matters.

Pixel Fine Converter measures the baseline difference between XD and Figma for major Japanese fonts and ships per-font correction coefficients. It’s how we cover the cases that a generic, formula-based correction can’t fully resolve on its own.

If you’d like the deeper technical background, there’s a companion article: → Blog: How accurately can Japanese text move from Adobe XD to Figma?

🤔 Why Japanese-specific correction is needed

XD and Figma use entirely separate text rendering engines internally. Even with the same font file:

• The baseline position (vertical reference for characters)
• How lineHeight is interpreted
• Anti-aliasing of glyphs

…all behave a bit differently, which produces vertical drift during conversion.

This drift exists for Latin fonts too, but it stands out for Japanese (CJK) fonts for two reasons:

• CJK fonts have differently-structured baseline metrics compared to Latin-only fonts
• Older Japanese fonts (like MS Gothic) were designed around bitmap rendering on Windows

Pixel Fine Converter has a generic formula-based correction baked in, but major Japanese fonts have idiosyncrasies that the generic path can’t always close to under 1px on its own. That’s where per-font precise correction comes in.

📐 Our approach — a measurement-backed font registry

For each major Japanese font, we measure the actual XD ⇄ Figma baseline difference and store the result as a correction coefficient inside a FONT_CORRECTIONS registry in the codebase.

When a new font matters:

1. Measure 42 cells (Regular / Bold × 7 sizes × 3 lineHeights) in both XD and Figma
2. Average the deltas to derive the per-font coefficient
3. Add it to the registry

This is how supported fonts grow over time. Rather than chasing “every font ever,” we focus on getting the most-used fonts right and expand from there.

✅ Supported fonts and accuracy

As of April 2026, the fonts below have precise per-font correction. All are based on 42-cell measurement, and post-correction average drift converges to under 1px.

Measurement summary:

• 📊 Test scope: 42 cells per font (Regular / Bold × 7 sizes × 3 lineHeights)
• 🎯 Post-correction accuracy: average baseline drift converges to under 1px
• 🔬 Method: real measurements from both XD and Figma — not estimates

🔧 Three correction patterns

Different fonts need different corrections. Pixel Fine Converter handles them in three patterns:

Pattern A: Generic correction (formula-based) is sufficient

Hiragino Kaku Gothic ProN, Yu Gothic, and Meiryo fall here. Their XD/Figma metric ratios (fontSize × ratio) sit inside the expected range, and the generic formula closes the gap to under 1px.

• No per-font registry entry needed
• New fonts with metric ratios near 1.40 get picked up automatically

Pattern B: A dedicated baselineOffset is required

Noto Sans JP and MS Gothic land here. Either they fall below the threshold of the generic correction, or they have an unusual ratio pattern, so we add a per-font baselineOffset for them.

• Noto Sans JP: baselineOffset = 0.86 (derived from 42-cell measurement)
• MS Gothic: baselineOffset = 2.25 (compensates for the under-threshold case)

Pattern C: The correction direction is inverted

Noto Sans CJK JP is the lone case here. The generic correction usually shifts the Figma side “down,” but this font needs an “up” shift instead. Applying the wrong direction would actually widen the drift — so we disable the correction with a dedicated flag.

⚠️ Out of scope — glyph rendering doesn’t align

Baseline position can be corrected, but the visual appearance of the glyphs themselves (stroke weight, overall feel, anti-aliasing softness) doesn’t align. That’s outside the scope of per-font correction.

• At the same fontSize: 14, characters can look bolder in XD / thinner in Figma
• Especially noticeable at MS Gothic small sizes (12–16px)
• The root cause is the difference between rendering engines (XD = OS-driven, Figma = browser-based custom)

We deliberately don’t try to correct this. If we silently scaled fontSize, Figma would end up holding a value different from what the original XD file says, which compromises the integrity of your data.

For the deeper technical background, see: → Blog: How accurately can Japanese text move from Adobe XD to Figma?

📝 What happens with unlisted fonts

Fonts not registered in FONT_CORRECTIONS (Morisawa fonts, FontWorks fonts, other Japanese typefaces, etc.) still get the generic formula-based baseline correction.

• If their metric ratio sits inside the expected range, the generic correction generally aligns them well
• If the ratio is far outside the range, alignment may not be perfect until a dedicated correction is added

If your font isn’t in the list, try the Free plan first. In most cases the generic correction lands within practical accuracy.

Requests for adding fonts to the registry are welcome via GitHub Issue or contact email. We’ll consider gathering measurements and adding the coefficient.

❓ Frequently asked questions (FAQ)

Q1. What happens if my font isn’t in the supported table?

Fonts not registered in FONT_CORRECTIONS still receive the generic formula-based baseline correction. For CJK text, when the XD/Figma metric ratio sits inside the expected range, the generic correction typically aligns the baseline to under 1px. If the ratio falls far outside the range, alignment may not be perfect — in that case, share measurement data via contact email and we’ll evaluate adding it to the registry.

Q2. Do Adobe Fonts and Google Fonts work?

Yes — as long as the font file name matches a registry key (e.g., Noto Sans JP, Noto Sans CJK JP), per-font correction is applied. Names that don’t match fall through to the generic correction. Google Fonts’ Noto Sans JP (static OTF) is already registered with a 42-cell-measured baselineOffset = 0.86. Adobe Fonts work the same way whenever font names align.

Q3. How do I get a new font added to the supported list?

Adding a font to the registry requires 42 cells of XD ⇄ Figma measurement data (Regular / Bold × 7 sizes × 3 lineHeights). Reach out via contact email or GitHub Issue with the font name and the measurement data, and we’ll work on deriving the coefficient and rolling it into a future release.

Q4. Is per-font precise correction a paid feature?

No — baseline correction for all six supported fonts is included on the Free plan. Both the generic formula-based correction and the per-font precise correction (baselineOffset / CJK correction disabled) apply with no additional purchase. The Pro plan covers a different axis: Auto Layout conversion (inferring Figma Auto Layout from XD stacks), Components conversion (preserving symbols as Components / Variants), and states-to-variants conversion (mapping hover / focus states to Variants). Consider Pro when you want to extend Japanese-design fidelity beyond baseline alignment into structural reproduction.

Q5. What should I check if drift remains after correction?

A few things to verify:

• Font name exactness: registry lookup is exact-match, so “Noto Sans JP”, “Noto Sans CJK JP”, “MS Gothic” must match precisely (spaces, hyphens, case)
• lineHeight structure: XD with AUTO lineHeight versus an explicit numeric value can produce different correction outcomes
• fontSize / language mix: if a single text layer mixes CJK and Latin, the CJK character-detection logic determines which branch runs

If drift over 1px persists after these checks, send measurement data via contact email.

Q6. Is the correction recalculated when I switch fonts inside Figma?

No — Pixel Fine Converter applies the correction only at conversion time. If you switch fonts inside Figma afterwards, the correction isn’t recomputed. The text-layer y position and lineHeight that Pixel Fine Converter set are preserved, but the new font has its own baseline metrics, so the correction’s effect isn’t guaranteed for the new font. For workflows that swap fonts often, change the font in XD first and re-convert, or split layers by font and re-convert per-font.

Q7. What about Japanese font issues that aren’t baseline drift?

Japanese fonts also have separate problems like “the font doesn’t show in Figma” or “how to swap fonts in bulk.” These are covered in dedicated articles:

• Figma fonts not showing — diagnostic steps — root-cause breakdown and resolution paths
• Japanese fonts in Figma — full guide — adding fonts, missing-font problems, XD migration caveats
• Bulk font replacement in Figma — built-in features versus plugin choices

🚀 Start with the Free plan

Pixel Fine Converter is free to install from Figma Community. The Free plan includes the basic conversion (shape / text / style / group / mask / image / transform) plus measurement-based baseline correction for all six major fonts (Noto Sans CJK JP / Noto Sans JP / Hiragino / Yu Gothic / Meiryo / MS Gothic).

The Pro plan (one-time $29, no subscription) pays off on the structural side, beyond baseline alignment: Auto Layout conversion (inferring Figma Auto Layout from XD stacks), Components conversion (preserving symbols as Components / Variants), and states-to-variants conversion (mapping hover / focus states to Variants). Consider Pro when layout and state fidelity matter as much as baseline.

Related pages

• Blog: How accurately can Japanese text move from Adobe XD to Figma? — An honest breakdown of what aligns and what doesn’t, with measured data
• Blog: Figma fonts not showing — diagnostic steps — root-cause breakdown and resolution paths
• Blog: Japanese fonts in Figma — full guide — adding fonts, missing-font problems, XD migration caveats
• Blog: Bulk font replacement in Figma — built-in features versus plugin choices
• Features: Fine-tuning — Four adjustments that bridge XD ⇄ Figma rendering differences
• Features: Auto Layout conversion — Inferring Figma Auto Layout from XD stacks
• Guide: Fine-tuning option reference — Defaults and details for each option