Non-Breaking Space Remover — Strip   and U+00A0 from Any Text

What a non-breaking space is and how it differs from an ordinary space

Unicode assigns code point U+00A0 to the non-breaking space character. In every standard font it renders visually identical to a regular space — U+0020 — and most text editors, browsers, and word processors display the two characters indistinguishably. The sole functional difference is how the line-breaking algorithm treats them. U+0020 is a legal line-break opportunity: a renderer may wrap the line at that point to fit content within its container. U+00A0 carries an explicit instruction to hold the adjacent words together no matter how narrow the container becomes. A product label that reads "500 ml" will always appear on a single line; the same label with a plain space may split with the number on one line and the unit on the next.

That instruction is the only functional difference U+00A0 adds over U+0020. The two characters have the same visual width and the same glyph in every font. Their byte representations differ: U+0020 is the single byte 0x20 in both ASCII and UTF-8; U+00A0 is two bytes — 0xC2 followed by 0xA0 — in UTF-8. Every system that processes strings byte-by-byte sees two distinct characters. Every system that renders strings to pixels sees the same visible gap. That mismatch between visual identity and computational identity is the root cause of every problem non-breaking spaces create in downstream systems.

Where non-breaking spaces come from

Word processors generate non-breaking spaces deliberately. Microsoft Word inserts U+00A0 automatically between a number and its unit of measurement — 5 km, 3 pm, 42 % — between a person's first and last name in certain language configurations, and anywhere the user presses Ctrl+Shift+Space. LibreOffice and Apple Pages follow similar conventions. These are intentional typographic insertions designed to prevent awkward line breaks in printed documents. When you copy a paragraph authored in Word and paste it into a plain text field, CMS editor, or database input form, every one of those non-breaking spaces travels with it. A document handed off by a writer may look clean on screen and carry dozens of U+00A0 characters that no reviewer noticed.

Web pages are the second major source. HTML authors write the named entity   deliberately to create fixed spacing — navigation separators, padding in table cells, blank lines in older email templates. When a browser parses that entity, it stores U+00A0 in the DOM. When a user selects and copies visible text from the page, the browser copies the underlying character stream rather than the original HTML markup. The copied text contains U+00A0 wherever the source HTML contained  . Content management systems compound the problem: their rich-text editors emit   automatically when they detect consecutive spaces, because two ordinary spaces collapse in HTML rendering and the editor tries to preserve the visual gap the author intended.

OCR software is a third significant source. When a scanner converts a printed page to text, the OCR engine reads spacing from pixel measurements rather than from any semantic encoding. A printed number followed by a percent sign, an abbreviation followed by its expansion, a product name followed by a model number — each follows typographic conventions the OCR engine recognizes. Many engines map those visually cohesive groups to U+00A0 rather than U+0020 because the pixel evidence suggests the author intended them as single units. The resulting file looks correct on screen but carries non-breaking spaces that cause failures in every downstream system that performs exact string comparisons.

Real failures non-breaking spaces cause

Search matching fails first. A product catalog that stores "iPhone 16" with U+00A0 returns zero results for a query that sends "iPhone 16" with U+0020. The two strings look identical in every user interface; the comparison fails because the byte sequences differ. This failure is widespread in e-commerce, where product names are copied from manufacturer press releases that use non-breaking spaces for typographic consistency. Support queues fill with tickets that describe correct-looking data that search cannot find, and the investigation usually ends with a developer running a hex dump to spot the character that made the strings unequal.

Excel formulas break in a predictable way. A cell displaying "42 000" looks like the number forty-two thousand but is stored internally as a text string, because U+00A0 is not a digit character. The SUM function skips it entirely. A VLOOKUP against a column of numbers finds no match. Excel's TRIM function does not help because TRIM removes only U+0020. The cell appears cleaned after TRIM and continues to misbehave in every formula that references it, silently producing wrong totals or empty lookups with no error message.

CSS text rendering exposes non-breaking spaces as layout anomalies in specific situations. An element styled with letter-spacing applies the extra spacing around U+00A0 just as it would around any other character. In dense layouts — card titles, navigation labels, data tables — a non-breaking space injected via paste produces a visible gap at a position where no gap belongs. In Chinese and Japanese text, where words run together without explicit separators, a single U+00A0 pasted from a foreign source creates a gap that looks like intentional design but appears in no style rule and breaks character-counting logic that assumes uninterrupted runs of CJK glyphs.

CSV parsing errors follow a reliable pattern. A value of "New York" with U+00A0 does not match a lookup for "New York" with U+0020. Geographic datasets exported from GIS software, financial records from trading platforms, and HR data from payroll systems frequently carry non-breaking spaces in proper nouns, place names, and measurement strings. Joining such a dataset against a reference table that uses ordinary spaces leaves rows unmatched that look correct in every preview tool but fail every automated join or lookup.

Programmatic traps and the whitespace matching problem

The whitespace shorthand character class in most regex engines matches ASCII whitespace: space U+0020, tab U+0009, newline U+000A, carriage return U+000D, and form feed U+000C. U+00A0 falls outside that set by default in Python's re module, Go's regexp package, Ruby's built-in regex, and PCRE. A pattern written to split text on whitespace, strip trailing spaces, or validate that a field contains no embedded spaces passes a string containing U+00A0 without complaint. The string reaches the database or downstream API looking clean from the pattern's perspective and fails every equality comparison that follows.

JavaScript is the exception that creates confusion. The ECMAScript specification requires JavaScript's whitespace class to match all Unicode characters in the White_Space property, which includes U+00A0. A developer who tests a whitespace-stripping pattern in a browser console sees it work correctly against non-breaking spaces, then deploys the same logic in a Python service and finds it fails against production data. JavaScript's trim method also strips U+00A0 from both ends of a string; Python's str.strip does not. The same input string behaves differently depending on which layer processes it first, and the difference is invisible until data reaches a system that performs byte-exact comparisons.

How to spot a non-breaking space without a tool

Three manual tests identify U+00A0 reliably. The first uses cursor movement: place the cursor immediately before a suspicious gap and press the right arrow key one character at a time. If the cursor takes two keystrokes to cross what looks like a single space, an extra character is present at that position. This test works in Microsoft Word, most browser input fields, and code editors that do not render non-printable characters as visible glyphs.

The second test uses Find and Replace with the exact visible string — the word before the space, the space itself, and the word after. If the search finds no match even though the text is clearly visible on screen, the space in the document is not U+0020. The third test uses a developer console: paste the suspicious text and read the character code at the space position. A value of 160 confirms U+00A0. A value of 32 confirms U+0020. The decimal difference of 128 maps exactly to the byte offset between the two code points in the Latin-1 Supplement block of the Unicode standard, and knowing that offset is the fastest way to write a targeted replacement in any language.

HTML entities for non-breaking spaces and Unicode relatives

HTML provides three interchangeable ways to write a non-breaking space in source markup. The named entity   appears in virtually every HTML reference and is the most recognizable form. The decimal numeric reference   expresses the same character using its decimal code point value. The hexadecimal numeric reference   uses the hexadecimal code point. All three expand to U+00A0 when a browser or HTML parser processes the document. When a user copies visible text from a rendered page, the copy operation captures U+00A0 regardless of which entity form appeared in the source markup, so the downstream string always contains the raw character rather than any of the three entity notations.

Two Unicode relatives are rarer but cause identical comparison failures when they appear. U+2007, the figure space, has the same advance width as a digit in fonts with fixed-width numerals and appears in financial documents and typeset tables where numeric columns must align cleanly. U+202F, the narrow no-break space, is explicitly non-breaking and appears in French typographic conventions before punctuation marks including guillemets, colons, semicolons, and exclamation marks. Both characters look like spaces in rendered output, both prevent line breaks, and both cause string comparison failures in systems that do not account for them. Neither is removed by a simple replacement that targets only decimal 160.