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 the contact form. We’ll consider gathering measurements and adding the coefficient 🛠️.

🚀 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) and the generic formula-based baseline correction.

To use the measurement-based precise correction for major fonts (Noto Sans CJK JP / Noto Sans JP / Hiragino / Yu Gothic / Meiryo / MS Gothic), upgrade to the Pro plan (one-time $29, no subscription) 🎁.

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
• 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