I check how your product handles Japanese input before you ship it: IME conversion, fonts, forms, CSV exports. You get a short report with screen recordings and the fix, usually within two days.
No access to your code needed. I use your product the way anyone in Tokyo would.
Enterto pick 仕様書, “spec”
Then your app does this
Sent before the kanji was picked. 送信済 means “sent”.
| 85 | bug reports about Japanese input or display, filed between 2024 and 2026 |
|---|---|
| 64 | different products they were filed against |
| 75% | were IME bugs. Most of those: Enter sends a half-typed message. |
| 23 | came back after an update or a redesign |
| 67,367 | likes on one Japanese post complaining that chat apps send on Enter |
From GitHub issues, vendor forums and posts on X, October 2026. Not exhaustive. I stopped at 85.
Japanese is typed as kana and converted to kanji, and Enter confirms each conversion. If your keydown handler doesn't check for IME composition, the message, prompt or form goes out mid-sentence. New AI chat inputs are the worst offenders right now.
The fix usually lives in one component. Ship a new chat panel or a mobile screen and the bug is back. Your Japanese users tend to find it before your team does.
Without lang="ja" and a Japanese font in the stack, browsers fall back to Chinese glyph shapes. Japanese readers notice at once, and it reads as “this wasn’t made for us.”
Full-width digits rejected as invalid. No furigana field. Family name forced last. Addresses that don't start with the postal code. CSV files that open as mojibake in Excel.
Playwright, Cypress and WebDriver have no API for IME composition. The Playwright request for one has been open since March 2021.1
Simulating it gets you close, but not all the way. When I sent Playwright's keyboard.press('Enter') during a composition in Chrome, the page received keyCode 13 and inserted a newline. A real IME sends keyCode 229 and commits the text instead.2
Safari is its own case. It orders key and composition events differently, and WebKit switched off its fix in 2026 after too many regression reports.3 A Chromium-only CI won't see Safari-only bugs.
Finding every input that needs it, and keeping it fixed release after release, is the hard part. That's the job.
input.addEventListener("keydown", (event) => { // Enter that confirms an IME conversion is not a submit if (event.isComposing || event.keyCode === 229) return; if (event.key === "Enter" && !event.shiftKey) { event.preventDefault(); send(); }});A short report, ranked by impact. Every issue comes with a recording, steps to reproduce and a suggested fix.
macOS · Windows 11 · Chrome, Safari, Edge · macOS Japanese Input, Google Japanese Input, Microsoft IME
event.isComposing is true or event.keyCode is 229.lang="ja" on the root element for the Japanese locale, and list a Japanese font before the generic fallback.+ 4 more issues, 2 of them in the signup form
An example. The product and findings are made up.
Your product URL and the flows that matter. Chat, editor, search, signup, checkout, exports.
macOS Japanese Input, Google Japanese Input and Microsoft IME, in Chrome, Safari, Edge and Firefox. iOS and Android if you need them.
Usually within two days. Reply to it with questions and I'll answer them.
Start with a free check. If it's useful, keep Japanese working with a check before every release.
$0 once
One check of up to three flows. I take on 10 teams a month.
$300 a month
Three-month pilot. Cancel anytime.
Prices in USD. Need Korean or Chinese checked too? Say so in the form.
Tell me about your product. I'll reply within two business days to agree on the flows.
$300 a month for three months, cancel anytime. Nothing to pay now. We agree on scope first.