U+FEFF is one of Unicode’s more confusing characters because its official name points to its original text-formatting role, while many people today encounter it in a completely different context.
Its Unicode name is ZERO WIDTH NO-BREAK SPACE.
But at the beginning of encoded text, U+FEFF can also act as a byte order mark, usually shortened to BOM, when the relevant encoding or protocol defines that role.
For new text that simply needs zero-width no-break behavior, Unicode prefers U+2060 WORD JOINER instead.
U+FEFF at a Glance
| Property | Value |
|---|---|
| Code point | U+FEFF |
| Unicode name | ZERO WIDTH NO-BREAK SPACE |
| Special role at the start of text | Can act as a byte order mark where the encoding or protocol defines it |
| Legacy text role | Zero-width no-break behavior |
| Preferred character for new zero-width no-break use | U+2060 WORD JOINER |
U+FEFF belongs to the wider subject of invisible and special space characters, but its encoding history makes it unusual even within that group.
Why Is It Called Zero Width No-Break Space?
The name reflects the character’s original use.
U+FEFF could be used as a zero-width character that prevented a line break between surrounding text.
That’s where the name ZERO WIDTH NO-BREAK SPACE comes from.
Unicode character names are stable, so the name has been kept even though recommended usage has changed.
Today, Unicode separates the two concerns more clearly: U+FEFF keeps its old no-break semantics for compatibility, while U+2060 WORD JOINER is preferred for new text that needs zero-width no-break behavior.
What Is a Byte Order Mark?
Unicode text eventually has to be represented as bytes when it’s stored or transmitted.
Some multibyte encodings can represent their units using different byte orders. In those cases, an initial U+FEFF may be used as a marker that helps software determine how the following bytes should be interpreted.
That marker is the byte order mark.
When U+FEFF is recognized as a BOM, it isn’t ordinary visible document content. It’s being used as part of the encoding representation.
U+FEFF at the Beginning of Text
If U+FEFF appears at the very beginning of a stream, the first question isn’t “why is there an invisible space here?”
The better question is:
Does this encoding or file format treat the initial U+FEFF as a BOM?
That matters especially with UTF-16, where byte order may need to be determined when the stream isn’t otherwise marked.
Other formats and protocols have their own rules, so you shouldn’t assume every initial U+FEFF is handled in exactly the same way.
Does UTF-8 Need a BOM?
UTF-8 doesn’t have byte-order ambiguity, so it doesn’t need a BOM to tell software whether the data is big-endian or little-endian.
An initial UTF-8 BOM can still be used as a signature in some environments, and some software creates or accepts it.
But it shouldn’t be treated as something every UTF-8 file automatically needs. Whether it belongs there depends on the protocol, file format, software, or interoperability requirements involved.
What If U+FEFF Appears in the Middle of Text?
That’s a different situation.
Outside a recognized BOM position, U+FEFF may represent its older ZERO WIDTH NO-BREAK SPACE semantics or may simply be an unexpected character introduced during processing.
For compatibility, old text can still contain U+FEFF in this role.
For new text, though, Unicode recommends U+2060 WORD JOINER instead.
An unexpected U+FEFF inside a string might therefore be:
- legacy text content;
- an artifact from encoding conversion;
- a BOM that was incorrectly preserved as ordinary text;
- or another context-specific processing artifact.
Where the character appears is an important clue.
U+FEFF vs U+2060 WORD JOINER
| Code point | Name | Modern use |
|---|---|---|
| U+FEFF | ZERO WIDTH NO-BREAK SPACE | BOM-related use where applicable; legacy no-break semantics retained for compatibility |
| U+2060 | WORD JOINER | Preferred for new zero-width no-break text behavior |
If your goal is simply to prevent a line break without adding visible space, WJ avoids the ambiguity attached to U+FEFF.
The modern line-breaking distinction is covered in Word Joiner vs Zero Width Space.
U+FEFF Is Not the Same as NBSP
U+00A0 NO-BREAK SPACE, or NBSP, and U+FEFF ZERO WIDTH NO-BREAK SPACE have related names, but they don’t behave the same visually.
NBSP has space width.
U+FEFF is zero-width.
For modern text, it’s usually more useful to compare NBSP with ordinary U+0020 SPACE, while U+2060 WORD JOINER is the modern character associated with U+FEFF’s old zero-width no-break function.
Why Can a BOM Cause Problems?
Problems usually happen when different pieces of software disagree about whether the leading bytes represent a BOM or ordinary text.
A program that understands the BOM may consume it as encoding metadata.
A program that doesn’t expect it may expose an unexpected leading character or fail because it expected something else to appear first.
That can matter in:
- source files;
- data imports;
- configuration files;
- text-processing pipelines;
- formats with strict expectations at the beginning of a file.
The exact effect depends on the file format and software involved.
Why Might U+FEFF Show Up After Copy and Paste?
If U+FEFF has become part of the actual text content, it can survive copying, conversion, or data processing just like other Unicode characters.
Because it normally has no visible glyph, you may not notice it until another system performs an exact comparison, parses the data, or reports an unexpected character.
If pasted text contains hidden characters you weren’t expecting, why copied text can contain invisible characters covers the broader troubleshooting process.
How Can You Detect U+FEFF?
Don’t rely on what the text looks like. Inspect the actual code points or, when you’re debugging an encoding issue, the file bytes.
If the decoded text contains:
U+FEFF
the next question is where it appears.
At the beginning: check the encoding, file format, or protocol to see whether it defines U+FEFF as a BOM.
Inside the text: investigate whether it’s legacy ZWNBSP content, an encoding artifact, or an incorrectly retained BOM.
Should You Delete U+FEFF?
Not until you know what it’s doing.
If it’s a recognized BOM, it belongs to the encoding representation rather than the ordinary document content.
If it appears inside the content, removing it may make sense when it’s accidental. But older text may have relied on its no-break behavior.
A safer workflow is:
- identify where U+FEFF appears;
- check the encoding or protocol involved;
- determine whether it’s acting as a BOM or as text content;
- when editing or generating new text, use U+2060 for zero-width no-break behavior where appropriate;
- remove U+FEFF only when that matches the intended data.
Why Is the Official Name Still ZERO WIDTH NO-BREAK SPACE?
Unicode character names are stable identifiers. They aren’t normally renamed just because recommended usage changes over time.
So the official name preserves U+FEFF’s historical purpose even though many modern developers encounter it mainly in connection with BOM handling.
That leads to one useful distinction:
BOM is a role U+FEFF can have. It isn’t the Unicode name of the character.
The Main Point
U+FEFF has two closely connected histories.
Its official Unicode name is ZERO WIDTH NO-BREAK SPACE, reflecting its original text-formatting role.
At the beginning of text, it can also act as a byte order mark when the encoding or protocol defines that interpretation.
For new text that simply needs zero-width no-break behavior, U+2060 WORD JOINER is the better choice.
If U+FEFF appears somewhere unexpected, check its position and encoding context before deciding that it should be removed.
1 thought on “U+FEFF: Byte Order Mark or Zero Width No-Break Space?”