Germany — Formatting Standards & Code Snippets
Number, date, time, currency, telephone and address formats used in Germany, with formatting code snippets in Java, C#, JavaScript and PHP.
Identity
Conventions at a glance
Numbers & currency
The "standard" column comes from CLDR conventions for the locale; the "live" column is produced right now by your browser's Intl implementation for the same locale, so you can compare and check what your users would actually see.
Dates & times
Telephone numbers
Postal code & address
Address format
Code snippets
Formatting code for Germany in four languages. Expected outputs are shown as comments; they are computed by your browser's ICU data, so Java, .NET or PHP builds with older CLDR data may differ slightly (typically the space characters and the position of the currency symbol).
Other countries
Notes on Germany and general i18n advice
Specific to Germany
General advice for every locale
- Never hard-code formats. Do not write
"dd/MM/yyyy"or"$" + amountin your code: ask the platform for the localized pattern (Intl.DateTimeFormat,DateTimeFormatter.ofLocalizedDate,CultureInfo.DateTimeFormat,IntlDateFormatter) and let CLDR data decide separators, symbol positions and word order. The patterns on this page are for reference and validation, not for copy-pasting into format strings. - Store UTC, format locally. Keep instants as UTC timestamps (ISO 8601 with
Z) together with the IANA zone that matters for display, and format at the last moment. Keep monetary amounts as integers of minor units or decimals with the ISO 4217 code, never as formatted strings. - Use ICU/CLDR-based APIs rather than the C library
setlocale/strftimefamily: they are consistent across platforms, cover all locales and are updated with CLDR. In PHP that meansext-intl; in Javajava.timewithDateTimeFormatter; in .NET the invariant globalization mode must be off to get ICU data. - Separate language and region. The language decides translations and most formats, the region decides currency, first day of week, measurement system and address layout. A user can legitimately want
en-DE. - Validate loosely, normalize strictly. Accept phone numbers and postal codes with or without spaces, then store them normalized (E.164 for phones, upper-case without extra spaces for postal codes). Use a maintained library (libphonenumber) for phones rather than regular expressions.
- Mind text expansion and direction. Translations can be 30–50% longer than English, and some locales are right-to-left; use flexible layouts and logical CSS properties (
margin-inline-start).