# Translating Your SaaS into German: What Actually Changes

> German UI text runs about 30% longer, short labels can triple, and you have to choose between du and Sie. Measured on real apps: text expansion, formality, number and date formats, typography, legal pages, and billing.
- **Author**: Mohit Sapat
- **Published**: 2026-10-13
- **URL**: https://www.babelize.co/blogs/translate-saas-into-german

---

<p class="lead">
    Germany is usually the first non-English market a SaaS product goes after, and the translation is the easy part. Strings get longer, the product has to choose how formally it talks, numbers and dates flip their separators, and the legal and billing pages need more than a translator. This guide covers what actually changes, with measurements from real open-source apps.
</p>

<h2>German Text Is About 30% Longer, and Short Strings Grow the Most</h2>

<p>
    "German is longer" is common knowledge. How much longer is worth measuring, because it decides how much room your buttons need. We compared the English and German UI strings of two widely used open-source apps, <a href="https://github.com/excalidraw/excalidraw" target="_blank" rel="noopener noreferrer">Excalidraw</a> and <a href="https://github.com/mastodon/mastodon" target="_blank" rel="noopener noreferrer">Mastodon</a>, character by character (placeholders and tags removed, untranslated strings skipped):
</p>

<table>
    <thead>
        <tr>
            <th></th>
            <th>Excalidraw</th>
            <th>Mastodon</th>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td>Translated strings compared</td>
            <td>566</td>
            <td>1,574</td>
        </tr>
        <tr>
            <td>Total length, German vs English</td>
            <td>+28%</td>
            <td>+29%</td>
        </tr>
        <tr>
            <td>Strings that got longer</td>
            <td>81%</td>
            <td>79%</td>
        </tr>
        <tr>
            <td>Strings at least 1.5x as long</td>
            <td>25%</td>
            <td>30%</td>
        </tr>
        <tr>
            <td>Short strings (1-10 characters): median growth</td>
            <td>+27%</td>
            <td>+50%</td>
        </tr>
        <tr>
            <td>Short strings: 1 in 10 grows by at least</td>
            <td>+88%</td>
            <td>+183%</td>
        </tr>
    </tbody>
</table>

<p>
    The averages are manageable. The tail is what breaks layouts, and it sits in the shortest strings: the labels on buttons, tabs, and menu items, where you have the least room. Some real pairs from those files:
</p>

<ul>
    <li>Undo -> <strong>Rückgängig machen</strong> (4.2x)</li>
    <li>Unmute -> <strong>Stummschaltung aufheben</strong> (3.8x)</li>
    <li>Retry -> <strong>Erneut versuchen</strong> (3.2x)</li>
    <li>Edit -> <strong>Bearbeiten</strong> (2.5x)</li>
    <li>Move canvas -> <strong>Zeichenfläche verschieben</strong> (2.3x)</li>
</ul>

<p>
    What to do about it:
</p>

<ul>
    <li><strong>Never give text a fixed width.</strong> Let buttons and tabs grow, and decide in advance what happens when they cannot: wrap, truncate with a tooltip, or move into an overflow menu.</li>
    <li><strong>Budget for 3x on labels under 10 characters</strong> and about 1.5x on sentences, not a flat 30%.</li>
    <li><strong>Test before you translate.</strong> A <a href="/blogs/pseudo-localization-testing-guide/">pseudo-locale</a> that pads every string by 40% shows where the layout breaks without waiting for a translator.</li>
    <li><strong>Turn on hyphenation for long compounds.</strong> German glues nouns together ("Zahlungsmethodenverwaltung"), and a single word can be wider than a narrow column.</li>
</ul>

<pre><code>/* Works only when the page declares its language: &lt;html lang="de"&gt; */
.card-title,
.table-header {
  hyphens: auto;
  overflow-wrap: break-word;
}</code></pre>

<p>
    <code>hyphens: auto</code> uses the browser's German dictionary, so it only works when the document or element has <code>lang="de"</code>. That is one more reason to set the <code>lang</code> attribute from the active locale instead of hardcoding <code>en</code>.
</p>

<h2>Du or Sie: Pick One Before You Translate Anything</h2>

<p>
    German has two forms of "you": informal <em>du</em> and formal <em>Sie</em>. Every sentence that addresses the user commits to one, so the choice affects thousands of strings, and switching later means retranslating all of them.
</p>

<p>
    Developer and consumer tools have moved toward <em>du</em>. In the German files we measured, Excalidraw uses informal forms (<em>du</em>, <em>dein</em>, <em>dich</em>) 60 times and formal <em>Sie</em> zero times; Mastodon uses informal forms 252 times against a handful of formal ones. Products that sell to banks, insurers, law firms, or the public sector usually stay with <em>Sie</em>, because that is how their customers write to each other.
</p>

<ul>
    <li><strong>Match how your customers talk to each other</strong>, not how your English copy sounds. Casual English does not automatically mean <em>du</em>.</li>
    <li><strong>Write the decision down</strong> in your style guide and glossary, and give it to every translator and every AI prompt.</li>
    <li><strong>Never mix the two.</strong> A product that says <em>du</em> on the dashboard and <em>Sie</em> in billing emails reads as two different companies. Search your German files for both forms before each release.</li>
</ul>

<h2>Numbers, Dates, and Currency Flip</h2>

<p>
    German swaps the roles of the comma and the period, writes the currency symbol after the amount, and puts the day before the month. The browser already knows all of this, as long as you format values with <code>Intl</code> instead of string templates. Every output below was generated by <code>Intl</code> in Node.js:
</p>

<pre><code>new Intl.NumberFormat("de-DE").format(1234567.891);
// "1.234.567,891"   (en-US: "1,234,567.891")

new Intl.NumberFormat("de-DE", { style: "currency", currency: "EUR" }).format(1299);
// "1.299,00 EUR "

new Intl.NumberFormat("de-DE", { style: "percent", maximumFractionDigits: 1 }).format(0.195);
// "19,5 %"   (note the space before %)

const date = new Date("2026-10-13T14:05:00Z");
new Intl.DateTimeFormat("de-DE", { dateStyle: "medium", timeZone: "Europe/Berlin" }).format(date);
// "13.10.2026"

new Intl.ListFormat("de", { type: "conjunction" }).format(["Rechnung", "SEPA-Lastschrift", "PayPal"]);
// "Rechnung, SEPA-Lastschrift und PayPal"</code></pre>

<p>
    "German" is also more than one locale. Switzerland and Austria format differently, so do not let <code>de-DE</code> stand in for every German speaker:
</p>

<pre><code>new Intl.NumberFormat("de-CH", { style: "currency", currency: "CHF" }).format(1299.5);
// "CHF 1'299.50"

new Intl.NumberFormat("de-AT", { style: "currency", currency: "EUR" }).format(1299.5);
// "EUR  1.299,50"</code></pre>

<p>
    Two more details: German uses the 24-hour clock in UI text, and the week starts on Monday, which matters for calendars, date pickers, and weekly reports. Our <a href="/blogs/javascript-intl-api-dates-numbers-currencies/">Intl API guide</a> covers the formatting APIs in depth, and the <a href="/blogs/locale-codes-bcp-47-explained/">locale codes guide</a> explains when to use <code>de</code> versus <code>de-DE</code>, <code>de-AT</code>, or <code>de-CH</code>.
</p>

<h2>Typography That Translators Get Right and Code Gets Wrong</h2>

<ul>
    <li><strong>Quotation marks</strong> are "like this" (low-high), not "like this". If your code wraps user content in quotes, the quotes belong in the translation string, not in the component.</li>
    <li><strong>Nouns are capitalized</strong>, so CSS <code>text-transform: capitalize</code> on English-style title case will mangle German. Let the translation decide capitalization.</li>
    <li><strong>Sentence fragments do not survive.</strong> "Delete" + " " + itemName works in English; German often needs the object before the verb. Translate whole sentences with placeholders, using <a href="/blogs/icu-messageformat-plurals-guide/">ICU MessageFormat</a> for counts.</li>
    <li><strong>Gender-inclusive language</strong> is a live style choice in German. Teams pick doubled forms ("Nutzerinnen und Nutzer"), neutral participles ("Nutzende"), or symbols ("Nutzer*innen"). Neutral forms are the least controversial and the easiest to keep short. As with <em>du</em> and <em>Sie</em>, pick one and apply it everywhere.</li>
</ul>

<h2>Legal Pages Are Not a Translation Task</h2>

<p>
    Some German requirements have no English equivalent, so translating your existing legal pages will not cover them. The usual list for a SaaS product with German customers looks like this; have a German lawyer review it, because this is a summary, not legal advice:
</p>

<ul>
    <li><strong>Impressum (legal notice).</strong> Commercial websites aimed at Germany must name the operator, a postal address, and contact details. Since May 14, 2024 the legal basis is <a href="https://www.gesetze-im-internet.de/ddg/__5.html" target="_blank" rel="noopener noreferrer">§ 5 of the Digitale-Dienste-Gesetz (DDG)</a>, which replaced the Telemediengesetz. An Impressum that still cites "§ 5 TMG" is out of date.</li>
    <li><strong>Datenschutzerklärung (privacy policy)</strong> under the GDPR (DSGVO in German), in German, covering every tool that processes personal data.</li>
    <li><strong>Cookie consent</strong> under the TDDDG, the renamed TTDSG: non-essential cookies and trackers need consent before they load.</li>
    <li><strong>A data processing agreement</strong> (Auftragsverarbeitungsvertrag, AVV). German business customers will ask for one before signing, along with where your data is hosted. Have it ready instead of drafting it during a deal.</li>
</ul>

<h2>Pricing and Billing Change Too</h2>

<ul>
    <li><strong>Show the right price.</strong> Prices shown to consumers must include VAT, which is 19% for most digital services in Germany. Business-only pricing pages can show net prices, marked "zzgl. MwSt." (plus VAT).</li>
    <li><strong>Collect VAT IDs</strong> for business customers in other EU countries so you can invoice under the reverse-charge rules.</li>
    <li><strong>Offer the payment methods Germans use.</strong> German shoppers rely on PayPal, SEPA Direct Debit, and paying on invoice (Kauf auf Rechnung) much more than shoppers in most Western markets, and cards make up a comparatively small share of online purchases. For B2B SaaS, accepting SEPA Direct Debit and paying an invoice by bank transfer removes a common blocker.</li>
    <li><strong>Localize the invoice itself.</strong> A German customer's accountant expects German labels, the correct VAT breakdown, and dates and amounts in German format.</li>
</ul>

<h2>A Practical Order of Work</h2>

<ol>
    <li><strong>Internationalize first.</strong> Move every user-facing string into locale files and format every number and date with <code>Intl</code>. Translating hardcoded strings is wasted work; see <a href="/blogs/i18n-vs-l10n/">i18n vs l10n</a> for the difference.</li>
    <li><strong>Run a pseudo-locale</strong> with 40% padding and fix the layouts that break, especially buttons, tabs, and table headers.</li>
    <li><strong>Decide <em>du</em> or <em>Sie</em></strong>, gender-inclusive style, and a glossary of product terms that stay in English.</li>
    <li><strong>Translate the UI</strong>, with a German speaker reviewing at least onboarding, billing, and error messages.</li>
    <li><strong>Handle legal and billing separately</strong>: Impressum, privacy policy, consent, AVV, VAT display, and payment methods.</li>
    <li><strong>Launch the German locale behind its own URL</strong> (<code>/de/</code>) with <a href="/blogs/hreflang-multilingual-seo-guide/">hreflang</a>, so German searchers land on German pages.</li>
</ol>

<p>
    If German is your first market after English, our guide to <a href="/blogs/choose-your-first-saas-languages/">choosing your first SaaS languages</a> covers how to sequence the next ones.
</p>

<h2>Frequently Asked Questions</h2>

<h3>How much longer is German text than English?</h3>
<p>
    In the English and German UI strings of Excalidraw and Mastodon, German was 28 to 29% longer in total, about 80% of strings got longer, and a quarter to a third grew by 50% or more. Short labels grow the most: one in ten short Mastodon labels grew by 183% or more.
</p>

<h3>Should a SaaS product use du or Sie in German?</h3>
<p>
    Developer and consumer tools increasingly use du, while products for conservative industries such as finance, insurance, law, and the public sector usually use Sie. Match how your customers write to each other, document the choice, and never mix the two forms in one product.
</p>

<h3>How do I format prices and dates for German users?</h3>
<p>
    Use the Intl APIs with the de-DE locale instead of string templates. They produce 1.299,00 EUR  for prices, 13.10.2026 for dates, and 19,5 % for percentages, and they handle Austrian (de-AT) and Swiss (de-CH) conventions too.
</p>

<h3>Does a SaaS website need an Impressum for Germany?</h3>
<p>
    Commercial websites aimed at German users generally need one. Since May 14, 2024 the requirement is in § 5 of the Digitale-Dienste-Gesetz (DDG), which replaced § 5 of the Telemediengesetz (TMG). Have a German lawyer confirm what yours must contain.
</p>

<h3>Which payment methods should a SaaS offer in Germany?</h3>
<p>
    Beyond cards, offer SEPA Direct Debit and payment by invoice or bank transfer, and consider PayPal for self-serve plans. German buyers use these methods far more than shoppers in most other Western markets.
</p>
---
- [All articles](https://www.babelize.co/blogs)