How accurately can Japanese text move from Adobe XD to Figma?

“I converted my XD design to Figma, and the Japanese text looks slightly off.” “Same fontSize, but the characters look thinner / smaller in Figma.” — these are common reactions from designers migrating from XD to Figma.

For Japanese designs, where pixel-level layout precision matters, those small visual shifts can become a real problem. At the same time, claims like “perfect conversion” or “flawless migration” that you sometimes see in converter marketing don’t really exist in practice.

In this article, based on Pixel Fine Converter’s measurements across 5 fonts × 42 cells, we’ll honestly break down what can be aligned and what can’t, and walk through the practical implications of each.

What you’ll get from this article

• Baseline position can be corrected — what the plugin actually does
• Visual glyph weight can’t be aligned — and why, technically
• The special case of MS Gothic and bitmap fonts
• Why we deliberately don’t auto-correct glyph appearance
• Practical guidance: move to modern fonts, and bump body sizes a little

📝 Why Japanese text looks slightly off after conversion

XD and Figma both fall under the “design tool” category, but their internal text rendering engines are completely separate. Even when both load the same font file:

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

…are all handled differently. The result: a design built in XD looks subtly different when opened in Figma.

This kind of drift exists for Latin fonts too, but it’s especially visible with Japanese fonts. There are two reasons:

1. CJK fonts (Chinese / Japanese / Korean) carry baseline metrics that are structured differently from Latin-only fonts
2. Older Japanese fonts like MS Gothic were designed around bitmap rendering on Windows, and don’t always play well with modern outline rendering

This article is about exactly where that line is — what the plugin can correct, and what it shouldn’t try to.

✅ What aligns — baseline position

Let’s start with the good news. Baseline position (vertical placement of text) can be corrected by the plugin.

Pixel Fine Converter measures the baseline difference between XD and Figma for major Japanese fonts and ships per-font correction values.

Concretely, what the plugin does:

• Identifies the font name and looks up the matching correction coefficient
• Applies that coefficient as baselineOffset to the position
• For Noto Sans CJK JP, the correction direction is reversed compared to other fonts → handled with a dedicated flag
• For MS Gothic, the default threshold doesn’t trigger correction → addressed with a new dedicated baselineOffset

In other words, per-font idiosyncrasies are stored in a “registry pattern” — when a new font becomes important, you measure it and add it. The design is built to be extensible.

→ See the list of supported fonts in Features: Japanese font handling

⚠️ What doesn’t align — visual glyph weight

Baseline is solved. But the visual weight of glyphs themselves isn’t something the plugin can correct for. You’ll see things like:

• Same fontSize: 14, but characters look bolder in XD / thinner in Figma
• Especially noticeable at MS Gothic small sizes (12–16px)
• The overall visual “weight” of the type can shift slightly
• Anti-aliasing softness differs, affecting outline crispness

This glyph-level drift isn’t the kind of thing you can correct with a number. It comes from differences in how each rendering engine is fundamentally designed — not from a simple offset you can compute.

🔧 Why it doesn’t align — different rendering engines

The root reason XD and Figma render Japanese text differently is that they use entirely separate text rendering engines.

In plain English:

• XD uses the OS’s font rendering directly — that means macOS and Windows look different (but each looks “natural” to its own OS)
• Figma uses its own rendering engine to stay consistent across OSes — which is great for cross-platform consistency, but it means it won’t match the “native look” of any specific OS

Both are reasonable design decisions on their own. They just lead to “the same design looks different” once you cross the boundary.

🔤 The MS Gothic case — bitmap fonts

Within Japanese fonts, MS Gothic is one of the most likely to look “wrong” after conversion. There’s a specific technical reason for that.

MS Gothic is a bitmap-era Windows 95 font

MS Gothic was designed for 1990s Windows as a Japanese gothic font, and it carries embedded bitmaps inside the font file.

• For commonly-used small sizes (12px, 14px, 16px), the rendered appearance is included as actual bitmap images inside the font
• This made small text look crisp on low-resolution displays without jagged edges
• It was a standard approach in the era before fonts like Meiryo arrived on Windows

How XD and Figma handle this differently

• XD (especially on Windows): tends to use the embedded bitmaps when available → sharp small-size appearance
• Figma: always generates from the outline (vector shape) → a different look at the same size

That gap is why MS Gothic at small sizes tends to look thinner / smaller in Figma than it did in XD.

So when you see drift on MS Gothic, the root issue isn’t really Figma — it’s that the font itself was built for a usage pattern that no longer matches how design tools work today.

🛠 Why we don’t correct it on the tool side

“If glyphs look thinner, why doesn’t the plugin auto-bump fontSize by ~5%?” It’s a natural idea. Pixel Fine Converter deliberately doesn’t do that. There are three reasons.

Reason 1: That’s no longer “conversion” — it’s “modification”

If your XD file says fontSize: 14 and we silently emit fontSize: 14.7 to Figma, that’s no longer faithful data migration. Later, someone will inevitably ask “why is Figma 14.7 when XD says 14?” — and that’s a confusing trail to leave behind.

Reason 2: The right correction varies by font / OS / Figma version

• 1.05× might be right for Font A but 1.03× is right for Font B
• The same font often needs a different value depending on the OS
• If Figma updates its rendering engine, every correction value needs to be re-tuned

In short, automatic correction can match “what the eye sees right now,” but it becomes a maintenance burden over time.

Reason 3: Baseline correction is safe; glyph correction is risky

Baseline position is “a measurable physical quantity, fixed at conversion time.” Visual glyph weight is “a subjective impression mixed with perception.” Correcting the former increases accuracy. Correcting the latter is guesswork.

💡 Practical recommendation — move to modern fonts

With the technical context out of the way, here are three practical recommendations.

1. Use modern fonts for new designs

The fonts below have mature correction support and play well with Figma’s rendering:

All of these have measurement-backed correction coefficients in Pixel Fine Converter, and baseline position aligns to under 1px.

2. Migrate MS Gothic gradually

Replacing every MS Gothic instance at once will likely break layouts.

• Don’t use it for new work (substitute with Yu Gothic / Noto Sans JP)
• Keep it on existing files (drift is visible, but the data stays accurate)
• Replace as part of a larger redesign, using Find & Replace in batch

3. Body text at 14px+ makes the drift much less noticeable

Rendering differences are most visible at small sizes.

• 12px and below: pixel-level drift is visible
• 14px and up: drift exists but rarely catches the eye
• 18px and up: differences become essentially imperceptible

From a web accessibility standpoint, 14–16px body text is the recommended range anyway. Just bumping the body size is often enough to make the rendering gap disappear in practice.

💬 Frequently asked questions

Q: How big is the baseline drift in concrete numbers?

A: It depends on the font and size, but before correction it can be 2–5px, and after correction it converges to under 1px. Pixel Fine Converter’s per-font correction coefficients are based on actual measurement across 5 fonts × 42 cells.

Q: Why not auto-correct glyph rendering? Is it just technically hard?

A: It’s technically possible. The problem is that the right correction value depends on the font, the OS, and the Figma version — so any auto-correction would match “today’s appearance” but need a full rerun every time Figma updates its rendering engine. Keeping the original XD data intact in Figma is safer in the long run.

Q: We have designs in MS Gothic. What should we do?

A: Three options. (1) Keep them as MS Gothic (visible drift, but data stays accurate); (2) Replace with Yu Gothic / Noto Sans JP during a larger redesign; (3) Substitute fonts on the Figma side while keeping the original XD spec, so you can revert later. Pick what fits your team’s situation.

Q: Is there a setting in Figma to make font rendering closer to XD?

A: No. Figma’s rendering engine is intentionally designed for cross-OS consistency, not for matching any specific OS or app’s appearance. There’s no official option to switch behavior.

Q: How does the Japanese-text fidelity compare to other converter plugins?

A: It depends on whether each plugin ships per-font baseline corrections. Coverage varies. For a side-by-side breakdown, see Comparing XD-to-Figma converter plugins.

🎯 Wrapping up

We’ve broken down the Japanese-text conversion question into “what aligns” and “what doesn’t.”

Key points

Trying to “match perfectly” forces you to fudge data somewhere along the way. “Align what’s alignable; don’t touch what isn’t” — that’s Pixel Fine Converter’s design stance, and we think it’s the right tradeoff for keeping your design data trustworthy long-term.

Related pages

• XD → Figma migration: a practical guide — concrete steps, prep, and QA after deciding to migrate
• Comparing XD-to-Figma converter plugins — Pixel Fine Converter vs. Angel Converter on four dimensions
• How long will Adobe XD be supported? — what maintenance mode means and when to migrate
• Features: Auto Layout conversion — Pixel Fine Converter’s Auto Layout coverage
• Features: Fine-tuning — correcting rendering differences between XD and Figma