- Japanese UI register — the politeness level woven through every sentence — is rarely decided deliberately, and that gap is the root cause of most "feels translated" complaints from Japanese users.
- For B2B SaaS and FinTech, teineigo (です・ます form) is the correct base register; button labels should use the nominal style (no verb ending) regardless of product type.
- Mixing registers across a single product — even when each individual string is correct — signals low quality to Japanese users and damages trust at every touchpoint.
- The fix is a register specification that precedes translation, not a QA check that follows it.
- Register is the first localization decision. Choosing teineigo, plain form, or a hybrid must happen before translation begins — not after QA surfaces inconsistencies.
- Button labels should always be nominal. Across all product types and registers, button labels in Japanese should use verb-less noun forms (保存, 削除, 送信) — adding する or します adds length without value.
- Error messages need teineigo even in casual products. The moment of system failure is when users need reassurance most. Plain-form error messages ("エラーが発生した") are alarming; polite form with an apology prefix guides users forward.
- Register inconsistency is more damaging than the wrong register. A product that applies teineigo consistently will outperform one that mixes registers — even if the mixed-register product has technically better individual strings.
- The "flow test" is the best QA check. Have a native Japanese professional read the entire product top to bottom and describe the tone in one sentence. "It varies" means you have a register problem.
The Question Nobody Tells You to Ask
When foreign SaaS companies localize into Japanese, the workflow typically looks like this: translate the strings, run them through a bilingual reviewer, ship. What almost never happens is a deliberate decision about register — the level of politeness woven through every sentence of your UI.
This is not a cosmetic concern. Japanese has several distinct politeness levels, and they say completely different things about your product. The wrong register doesn't just sound odd; it tells the reader your product doesn't understand its own audience. In Japanese B2B SaaS, that signal often kills trust before the user ever reaches the pricing page.
The good news: once you see how register works in SaaS Japanese, picking the right one becomes systematic. This article gives you a practical framework — and before/after examples — to make that call confidently for every touchpoint in your product.
Register isn't about being polite or casual. It's about sounding like a product that was built for Japan — not exported into it.
What "Register" Actually Means in Japanese SaaS
In linguistics, "register" means the level of formality a speaker or writer uses — and in Japanese, it's far more structured than in English. Most non-native speakers see Japanese politeness as a binary: keigo (polite) vs. plain form (casual). In practice, SaaS products work across at least four distinct levels, each sending a different signal to Japanese users.
尊敬語 / 謙譲語
丁寧語（です・ます）
体言止め混在
普通体（だ・である）
The key insight is that these levels aren't simply "more polite" or "less polite" versions of each other. They send fundamentally different signals. Teineigo signals professionalism and respect. Sonkeigo signals institutional weight. Plain form signals informality — which works for consumer apps but often reads as careless in B2B products. The hybrid nominal style (verb-less, noun-final) isn't a compromise; it's the right choice for button labels and UI actions across nearly all product types.
Why the Wrong Register Costs You More Than You Think
Japanese users do not consciously analyze register when they use a product. But they feel it immediately when something is off. The most common register mistakes in localized SaaS products fall into three categories:
- Over-formality: sonkeigo in UI copyUsing deferential honorifics throughout a self-service SaaS product creates friction. When every button reads like a formal letter, the interface feels heavy and slow — not professional.
- Under-formality: plain form in B2B toolsPlain form (da/de aru endings) carries an informal, occasionally blunt tone that is appropriate for developer CLIs or consumer apps — but feels dismissive in enterprise software, FinTech, or any product where the user is trusting your platform with their data or money.
- Inconsistency: mixing registers across pagesThis is the most common and most damaging mistake. When your onboarding flow uses teineigo, your error messages use plain form, and your pricing page oscillates between both, the product feels internally inconsistent — and internal inconsistency reads as lack of quality control.
The inconsistency problem deserves emphasis. In QA reviews I run on localized SaaS products, register mixing sits in my top three findings almost every time, and it traces back to the same root cause: different strings were translated at different times, by different tools or translators, with no register spec in hand. Each individual translation may be acceptable. Stitched together, they produce a product that feels assembled — not designed.
The Decision Framework: Which Register Is Right for Your Product?
Register choice isn't arbitrary. It follows from three factors: your product type, your target user, and your brand positioning. Here's a practical decision matrix covering the SaaS categories I see most often entering the Japanese market.
| Product Type | Target User | Recommended Register | Avoid |
|---|---|---|---|
| B2B SaaS (HR, CRM, ERP) | Enterprise buyers, managers | Teineigo throughout | Plain form, over-formal sonkeigo |
| FinTech / Payment platform | Finance teams, CFOs | Teineigo + sonkeigo in legal/billing | Plain form anywhere in payment flow |
| Developer tools / APIs | Engineers, CTOs | Nominal + plain form in docs | Heavy keigo in technical UI |
| Consumer / Productivity app | Individual users, freelancers | Teineigo UI + nominal buttons | Sonkeigo (feels overly stiff) |
| AI / Copilot tools | Knowledge workers | Teineigo UI + plain in AI responses | Inconsistent mixing within flows |
| Security / Compliance SaaS | IT admins, compliance teams | Teineigo + sonkeigo in alerts | Plain form in security-critical messages |
One nuance: even within a single product, different contexts call for different register sub-levels. Button labels should almost always use the nominal style (no verb ending) regardless of product type — it reads as clean and intentional across all registers. Prose descriptions, tooltips, and onboarding messages should match the product's overall register. Error messages and security alerts should lean toward teineigo even in otherwise casual products, because the moment of system failure is exactly when you need to reassure, not alarm.
Before and After: Register in Action
The difference between registers is most visible at the specific touchpoints where users form their strongest impressions of product quality. Here are eight of the most common UI contexts — and how register should be applied at each.
| UI Context | ❌ Common Mistake | ✅ Recommended |
|---|---|---|
| Primary CTA button | 無料トライアルを開始する （Verb form — reads as instructional） |
無料で試してみる （Invitation tone — feels user-led） |
| Save action button | 変更を保存します （Polite verb — too wordy for a button） |
変更を保存 （Nominal — correct for all button labels） |
| Success message | 保存した （Plain form — abrupt, cold） |
保存しました （Teineigo — warm, confirms completion） |
| Error message | エラーが発生した （Plain form — alarming, no reassurance） |
エラーが発生しました。恐れ入りますが、再度お試しください （Teineigo + apology — guides forward） |
| Onboarding tooltip | ここをクリックしろ （Command form — rude, instructional） |
こちらをクリックしてください （Polite request — guiding, respectful） |
| Pricing CTA | 今すぐ購入する （Pushy — creates resistance in B2B） |
プランを選択する （Neutral invitation — lets user feel in control） |
| Destructive action | 削除しますか？ （Question — lacks gravity for irreversible action） |
削除してよろしいですか？この操作は元に戻せません （Formal check + consequence — appropriate weight） |
| Empty state message | データなし （Plain label — cold, unhelpful） |
まだデータがありません。最初のレコードを追加してみましょう （Teineigo + invitation — supportive） |
What Keigo and Plain Form Signal to Japanese Users
Beyond individual touchpoints, the register choice shapes the entire perceived identity of your product. These two columns summarize what each primary register signals at the product level — helping you match your localization choice to your brand positioning in Japan.
The takeaway is that neither register is universally better. The question is whether your register choice is intentional — made in advance, specified in your style guide, and enforced across every product string. Most localization problems aren't problems of the wrong choice. They're problems of no choice — strings that defaulted to whatever the translator or AI tool produced, with no register brief in hand.
Touchpoint-by-Touchpoint Register Guide
For most B2B SaaS products entering Japan, the following per-touchpoint guide applies. Adapt based on your product type and audience using the decision matrix above.
Consistency Is the Real Goal
The most important register principle for SaaS localization isn't which level you pick — it's that you pick one deliberately and hold it everywhere. A product that uses teineigo consistently, even if a more formal register might theoretically be slightly better, will outperform a product that mixes registers without intention.
This matters because Japanese users read UI language holistically. When they hit an error message that sounds different from the onboarding flow, or a pricing page that shifts register mid-paragraph, they don't think "interesting stylistic choice." They think "this product doesn't quite feel finished." That perception is hard to undo without a systematic QA review.
-
1Define your register before you translate Before any string enters your localization workflow, specify: "This product uses teineigo throughout the UI, nominal style for all button labels, and teineigo with an apology prefix for all error messages." This single specification prevents the majority of register problems.
-
2Audit button labels separately Button labels are the most common register violation in localized SaaS products. Run a targeted audit of every button string and confirm they all use nominal style — no verb endings, no polite suffixes.
-
3Check your error messages as a set Pull every error and warning message into a single view and read them consecutively. Inconsistencies that are invisible when reviewing strings one at a time become obvious when you see them as a set.
-
4Flag any string that ends in 「だ」 or 「である」 In B2B SaaS, plain-form endings are almost always wrong. Automated tools can search for these endings in your string files and surface candidates for register correction before they ship.
-
5Get a native reader to do the "flow test" The most reliable register check is qualitative: have a native Japanese professional read the product top to bottom — from landing page through onboarding to account settings — and describe the overall tone in one sentence. If the answer is "it varies" or "it shifts," you have a register problem regardless of what the individual strings look like.
Register isn't a finishing detail in Japanese SaaS localization. It's the first decision.
The question "should we use keigo or plain form?" has no universal answer — but it has a right answer for your product, your audience, and your brand positioning in Japan. What it never has is a good default. Leaving register to chance means leaving your product's trust signal to chance.
In Japan, the companies that succeed long-term are the ones that sound like they made a decision about how they speak to their users — and then held that decision across every string, every touchpoint, every release. That consistency isn't just linguistic quality. It's commercial commitment, visible through language.
Should my SaaS product use keigo or plain form Japanese?
For B2B SaaS, FinTech, and enterprise tools, teineigo (desu/masu form) is the correct choice throughout the UI. Developer tools and consumer apps may use a more casual register. The most important factor is consistency — choosing one register and applying it across every touchpoint. A product that applies teineigo consistently will outperform one that mixes registers, even if the mixed-register product has technically more precise individual strings.
What is the difference between keigo and plain form in Japanese UI?
Keigo (polite form) uses desu/masu endings and signals professionalism and respect — appropriate for most B2B software. Plain form (da/de aru) is more informal and works for developer CLIs or consumer apps. Button labels should use the nominal style (no verb ending) regardless of product type — for example, 「保存」 instead of 「保存する」 or 「保存します」. Noun-final button labels are accepted across all registers and reduce length.
Why does register consistency matter in Japanese SaaS localization?
When different parts of a product use different politeness levels — for example, teineigo in onboarding but plain form in error messages — Japanese users perceive the product as inconsistent and unprofessional. This erodes trust and lowers conversion rates, particularly in B2B contexts where linguistic quality signals operational quality. Register mixing almost always stems from strings being translated at different times by different tools or people, with no register specification provided.
What Japanese politeness level should error messages use?
Error messages should always use teineigo (polite form), even in otherwise casual products. They should include an apology prefix such as 「恐れ入りますが」 or 「申し訳ございません」 and close with a clear next step. Plain-form error messages like 「エラーが発生した」 feel cold and alarming, damaging trust at precisely the moment users need reassurance.
When is plain form acceptable in a Japanese SaaS product?
Plain form is appropriate in developer tools, CLI documentation, and technical API references where engineers expect direct, compact language. It also works for AI assistant responses in copilot-style tools where a conversational tone is intentional. In both cases, the decision to use plain form should be deliberate and consistent — not the result of AI translation defaulting to casual output without a register brief.