A lookup returns nothing
The value looks identical on screen, and a VLOOKUP, a SQL WHERE clause or a deduplication check treats it as a different string. Non-breaking hyphens are a frequent culprit in “the value is definitely there” bugs.
Free · Private · No sign-up
A non-breaking hyphen looks exactly like the one on your keyboard and refuses to behave like it. This tool converts every one of them to a plain hyphen, a space, or nothing.
The non-breaking hyphen (‑, U+2011) was added to Unicode for one job: joining the parts of something that must never be split across a line — 555-0134, AN-4471-B, Jean-Pierre, 2-4-17. It renders like a normal hyphen in every font, so the two are impossible to tell apart on screen, and they are different characters to every program that compares strings. That is the whole problem: text that looks correct and fails to match.
It gets into your data through a paste. Word inserts it with Ctrl + Shift + - and Google Docs offers it under Special characters; InDesign, LaTeX and typesetting pipelines emit it automatically where a break would be harmful; and a PDF or web page that used it hands it straight to your clipboard. From there it travels into a spreadsheet, a support ticket, a customer record — and then a lookup for “555-0134” returns nothing while the record sits on screen looking exactly like the value you searched for.
This tool replaces exactly U+2011, so ordinary hyphens, en dashes and em dashes are untouched. The default replacement is the plain ASCII hyphen, which is what you want for anything a machine will read: the number still reads as a phone number, sorts with the rest of the column, and matches what people type. Choose a space when the hyphen was only separating two words, and Nothing to delete it — useful when the parts were never meant to be joined in the first place.
The symptoms are all the same shape: text that looks right and does not match.
The value looks identical on screen, and a VLOOKUP, a SQL WHERE clause or a deduplication check treats it as a different string. Non-breaking hyphens are a frequent culprit in “the value is definitely there” bugs.
U+2011 sorts after ASCII digits and letters rather than with the hyphen, so a pasted batch of identifiers can land at the bottom of a column instead of next to its neighbours.
Phone-number and postcode validators, older APIs and CSV loaders usually allow only ASCII. A non-breaking hyphen inside a field is an invalid character with no visible cause.
The character’s whole purpose: in a narrow column a long part number can push the layout wide or overflow, because the hyphen refuses to be a break point. If that is the behaviour you want to keep, keep the character.
The default and the safe answer. ASCII, one byte, recognised by every system, and it still reads as a phone number or a code to a human.
Use it when the character sat between words rather than digits — a hyphenated pair that should be two words after all.
Deletes the character so the two halves fuse. That is what a slug, an account key or a username wants.
One rule applies to the whole paste, so a column of a thousand values is the same job as a single line. Paste it in, copy the clean column back out — there is no upload and no row limit.
Three different hyphens in Unicode, three different jobs — pick the page that matches the one in your text.
How to type one in Word and Docs, and when to keep it.
The other invisible hyphen — remove U+00AD from PDF paste.
Swap ordinary hyphens for spaces, underscores or nothing.
Fix the U+2015 dash that shows as an empty box.
Clear every dash family in one pass, visible or not.
No sign-up, no upload, no word limit. Paste, pick, and copy the result.
Remove dashes now