Processed locally
Your input stays in this browser.
Most common barcode symbologies, including Code 128 and Code 39, are defined over the ASCII character set, which does not include letters such as a, o, u with umlauts, or a sharp s. A generator that accepts one of these characters is either transliterating it, rejecting it, or relying on an extension the receiving scanner may not support, so a label needing accented text has to pick a deliberate strategy rather than assume unaccented and accented input will scan the same way everywhere.
Why 'the alphabet' means something narrower than you'd expect
When people search for a barcode generator that handles German, French, or other accented text, they are running into a boundary that has nothing to do with any particular tool's quality: the widely used linear barcode symbologies were standardized around the ASCII character set, a 128-character repertoire limited to the unaccented Latin letters, digits, and common punctuation used in English-language computing from decades ago. Accented letters and the German sharp s are not part of that base repertoire, so a symbology that encodes 'the full ASCII range' is, despite the reassuring phrase, still not covering every letter that appears in ordinary German or French business text. This is a property of the format, not a limitation of any specific generator you might be using.
What Code 128 actually covers, and what it does not
Code 128, as specified by ISO/IEC 15417, encodes the full ASCII character set — commonly described as all 128 ASCII characters — across its three internal code sets, which makes it one of the more flexible linear symbologies for general text. Full ASCII still stops short of accented Latin letters and the German sharp s, because those characters live outside the 128-character ASCII range in the wider character encodings, such as Latin-1 or UTF-8, that most software and web pages actually use to represent them today. A generator built strictly to the Code 128 standard will therefore not have a defined, standard way to encode an accented letter directly; anything beyond plain ASCII depends on an extension or convention that the specific reader on the other end also has to support, which cannot be assumed.
| Symbology | Standard character coverage | Umlauts and other accented letters |
|---|---|---|
| Code 39 | uppercase, digits, limited punctuation | not covered |
| Code 128 | full ASCII (128 characters) | not covered |
| QR code, UTF-8 byte mode | full Unicode text | covered |
Worked example: a German product name with an umlaut
Take a product name such as Muesli, written with an umlaut over the u in the original German, intended for a Code 128 internal label. Encoded literally, that accented letter falls outside the symbology's standard character set, so a generator following the specification exactly should either reject the character, substitute it, or apply a non-standard extension specific to that generator's implementation. None of those outcomes is obviously wrong in isolation, but each produces a different actual barcode from the same typed input, and only one of them will match what a separately built receiving system expects to decode. The practical question is not whether a generator can produce some symbol from that input — most will — but whether the resulting encoded string is the one your receiving software, warehouse system, or trading partner actually expects to see.
Three practical strategies, and their trade-offs
The most portable strategy is transliteration: encode the plain-ASCII spelling instead of the accented one, accepting a small loss of visual fidelity in exchange for a string that any Code 128 or Code 39 reader anywhere will decode identically and unambiguously. A second strategy is to encode a plain identifier — an internal SKU or reference number — in the barcode itself and keep the accented display name only in human-readable text printed beside the symbol, which sidesteps the character-set question entirely because the barcode never has to carry the accented text at all. A third is to use a symbology and encoding mode built for wider character support, such as a QR code using UTF-8 byte mode, which handles accented Latin characters natively and is the more appropriate choice when the readable text itself, not just an identifier, genuinely needs to travel inside the code.
Why a symbol can render without an error and still be wrong downstream
A generator that quietly accepts an accented character and renders something is not proof that the choice was safe, because the rendering step and the receiving system's parsing step are two separate pieces of software that do not have to agree on what an out-of-range character should become. One vendor's Code 128 implementation might map an accented letter to its closest ASCII equivalent, another might reject it outright, and a third might pass through a raw byte that a different decoder interprets as a completely different character. All three behaviours are internally consistent and none of them is malfunctioning; they simply disagree about an edge case the base standard never defined, which is exactly why relying on default behaviour across two independently built systems is the mistake, not any single implementation.
Mistakes that surface only when the label reaches another country
A label validated only within one organization's own generation and scanning pipeline can behave consistently for months, because the same software handles both sides and its particular choice about accented characters is applied the same way every time. The mistake surfaces when the label crosses into a different system — a trading partner's warehouse, a different point-of-sale platform, a different country's logistics provider — that made a different implementation choice for the same out-of-range character, and a string that decoded correctly internally decodes as something else, or fails outright, on the other side. Testing an accented-text barcode only against your own reader is not a sufficient test if the label will ever be read by equipment you do not control.
Where this decision belongs, and where it does not
Deciding how to handle accented characters is a data-design decision that belongs upstream of the barcode generator, in the same place that decides field lengths, allowed character sets, and identifier formats generally — not inside the generator itself, which can only apply whatever rule it was built with. If accented text must survive a scan exactly as typed, choose a symbology and encoding mode, such as QR code with UTF-8 byte mode, that is actually specified to carry it, rather than hoping a linear symbology's undefined behaviour for out-of-range characters happens to match on both ends. For an internal identifier that does not need to be human-readable in the barcode itself, the simplest fix remains not encoding the accented text at all.
Why some generators offer an extended Latin mode anyway
A number of Code 128 implementations offer a mode, sometimes described as extended or full 256-character Code 128, that uses an additional function character to shift into a second bank of characters covering much of the Latin-1 range beyond plain ASCII. Where a generator and a receiving decoder are both built by the same vendor, or are both explicitly documented as supporting this specific extension, an umlaut can genuinely round-trip correctly through it. The caution is the same one that applies to every non-standard extension: it works only where both ends have implemented the same convention, and there is no single universal guarantee that a third party's scanner, unrelated to the generator's vendor, will interpret those extended characters the same way. Confirm support on the specific receiving hardware before relying on it, rather than assuming the option existing in the generator means it is safe everywhere. A practical way to confirm it is to generate a small, clearly labelled test batch containing the specific accented characters the real label will need, send it through the exact scanning and receiving pipeline the production label will use — not a phone camera app used only for a quick visual check — and compare the received text character by character against the source. If even one accented character comes back wrong, subtly different, or as a placeholder symbol, treat the whole extended mode as unsupported on that pipeline rather than assuming the remaining characters are fine because most of the test passed; character-encoding failures are often inconsistent across the specific characters involved rather than uniform across the whole set. ISO/IEC 15417:2007 Code 128 bar code symbology specification is the named source for the current external rule or product behaviour.