in HTML Email: What a Non-Breaking Space Does

  is the code for a non-breaking space in HTML, the language email designs are written in. It produces the character U+00A0, which looks like a normal space but never lets a line break there. In a booking email that says "7.30 pm", it keeps "pm" from starting the next line on a phone.

Seeing the letters   printed inside an email you received? The fault lies in how the sender built the email. Nothing is wrong with your inbox or your settings.

What   means in HTML

  is a named character reference: a short code the browser or email app swaps for one character. The HTML Standard's list maps it to U+00A0. Unicode names that character no-break space; its Unicode 1.0 name was non-breaking space.

The same character can also be written as a number:   in decimal or   in hexadecimal. Each spelling gives the reader the same U+00A0.

It differs from a normal space in two ways. First, the Unicode Standard gives it the width of a space but allows no line break beside it. In our Chrome test, both measured 4.45 px in 16 px Arial.

Second, it never collapses. CSS (Cascading Style Sheets) squeezes a run of spaces into one and drops spaces at the end of a line. CSS Text Level 3 applies those rules only to the space, the tab and line breaks.

That second rule explains a lot of email code. Three   in a row show as three spaces, and a table cell holding only   is not empty.

Browsers still read &nbsp without its semicolon in body text. The HTML Standard counts that as a parse error, and in a link address &nbsp= stays as typed, so write   in full.

When to use   in an email

Put   between two short pieces of text that lose their sense when split across lines. In email, that means pairs like these:

Pair	Write it as	What can happen with a normal space
Time and am or pm	7.30 pm	"pm" starts the next line
Day and month	14 November	The date splits over two lines
Phone number groups	020 7946 0321	Half the number ends one line
Number and unit	10 kg, 2 days	The unit sits alone
Last two words of a heading	start on Monday	One word alone on the last line

We tested a booking line and a heading in headless Chrome 156 in October 2026, at every width from 240 to 400 px. With ordinary spaces, the phone number broke at 49 of those 161 widths. "7.30 / pm" broke at 27 and "14 / November" at 25.

The heading left "Monday" alone on its last line at 41 widths. With   in those places, nothing split at any width.

This is the 272 px result, the text width of a 320 px phone screen with 24 px side padding. A ~ marks each  :

Normal spaces
  Our winter opening
  hours start on
  Monday
  Your table for two is booked for 7.30
  pm on Friday 14 November. To
  change it, call 020 7946 0321.

With  
  Our winter opening
  hours start
  on~Monday
  Your table for two is booked for
  7.30~pm on Friday 14~November. To
  change it, call 020~7946~0321.

A web page could use white-space: nowrap for the same job. Email is less dependable here: caniemail's test marks that property unsupported in classic Outlook for Windows, the 2007 to 2019 desktop versions it covers, and in Samsung Email (caniemail, tested 2019). The character travels inside the text, so it needs no CSS support.

Keep each tied group short, because it cannot break anywhere. An eight-word sentence joined entirely with   ran to 382 px in our 272 px column and spilled past the edge.

It will not hold text next to an image either. The same CSS specification keeps a break opportunity on both sides of an inline image, even beside U+00A0.

When we tested an icon followed by  9am, the two split onto separate lines at 36 of 131 widths. Two words joined the same way never split.

Spacer cells and empty blocks

The second job of   in email is giving an empty element a height. An empty cell has no line of text, so it has no height of its own. A plain space does not help, because CSS removes it.

These are the heights Chrome 156 gave the middle row of a three-row table:

Spacer markup	Height in our test
<td></td>	0 px
<td> </td>	0 px
<td>&nbsp;</td>	18.5 px, one line of 16 px Arial
<td style="font-size:1px;line-height:1px">&nbsp;</td>	1 px
<td style="font-size:20px;line-height:20px">&nbsp;</td>	20 px
<td height="20"></td>	20 px

Chrome also kept height="20" on an empty cell. What fails is CSS height on a div or paragraph: caniemail records Outlook for Windows ignoring it. Its line-height also needs mso-line-height-rule: exactly to behave.

A spacer with one   and a matching font size and line height does not rely on the height property. The line of text sets the gap:

<div style="height:20px; line-height:20px; font-size:20px; mso-line-height-rule:exactly;">&nbsp;</div>

When not to use  

A short gap inside one line of text is fine, such as the spaces around a vertical bar between two footer links. Indents, gaps between buttons, fake columns and spaced-out letters belong to padding, table cells and letter-spacing.

Spaced-out letters are the worst case. The W3C Web Accessibility Initiative (WAI) lists H E L L O as a failure in technique F32. A screen reader may read each letter instead of the word.

The CSS letter-spacing property gives the same look and keeps the word whole. On caniemail, it works in Gmail, Apple Mail and Yahoo, with partial support in Outlook for Windows.

Gaps and indents belong in cell padding. That is the one place Outlook for Windows applies padding, by caniemail's record. Alt text and clear link wording sit on the same checklist in email newsletter design.

Why editors add non-breaking spaces

An   in a template is not always deliberate. A browser collapses a second space, so an editor that wants to keep what you typed has to write a non-breaking one.

We typed into an editable box in Chrome 156 and read back the HTML it saved:

What we typed	HTML saved
Two spaces between words	Hello  world
Three spaces between words	Hello   world
One space at the end	Hello world 
Two spaces, box set to white-space: pre-wrap	Two plain spaces, no  

A W3C editing draft describes the same alternating pattern. So a template built in another tool can hold   wherever someone pressed the space bar twice.

Those extras can go back to a single normal space. Keep the ones that sit inside a pair, such as 7.30 pm.

Why   shows up as text in an email

When the HTML part of an email shows   as text, the code was encoded twice. Each round of escaping turns & into &. The source then holds  , which the reader's email app decodes once into six visible characters.

Our test page rendered these three lines:

In the HTML source           What the reader sees
Hello there             Hello there
Hello there         Hello there
Hello there     Hello there

One route in is a field built for plain text. A preview text box, or a merge tag value imported from a system that stores HTML codes, such as a CRM (customer relationship management) export, goes into the HTML as text. A tool that treats it as text escapes its ampersand like any other character.

A subject line is different. It is a plain header field, not HTML (RFC 5322, the internet standard for email messages), so   typed there is never decoded.

The plain-text version is the other place it shows. An email carrying both versions is sent as multipart/alternative, and RFC 2046 lets the email app pick the part it can show best.

Character references only mean something in HTML. A text part made from the HTML without decoding them prints   exactly as written.

The fix sits with the sender. Type plain words into plain-text fields, and replace   with   in the HTML. In the text version, use a normal space.

 before spaces and pound signs

A stray Â comes from the same character with a different fault: the wrong character set. In UTF-8, U+00A0 is stored as the two bytes C2 A0 (RFC 3629). Software that reads them as Windows-1252 shows the C2 byte as Â.

Our test page held a raw £ and a raw non-breaking space, declared as windows-1252. It displayed Tickets: £12 each.

The same line written as £12 each displayed correctly. ASCII (the basic 128-character set) reads the same in either encoding, and references are pure ASCII.

The preheader filler: ‌, ͏ and  

Some templates follow the preheader with a long run such as ‌ ‌ . The preheader is the hidden line written for the inbox preview. The run tries to fill the rest of that preview with blanks, so "View in browser" or other early text stays out of it.

We found no documentation from Gmail, Outlook or Apple Mail on how they choose preview text. The filler is a workaround email developers test, not a standard.

These characters turn up in such runs and elsewhere in email code. Widths are from the same Chrome measurement, and descriptions from the Unicode Standard and its character data.

Code	Character	Width	What it does
 	U+00A0 no-break space	4.45 px	Space-width gap with no line break beside it
‌	U+200C zero width non-joiner	0 px	Stops letters joining in scripts such as Persian
͏	U+034F combining grapheme joiner	0 px	Combining mark for sorting and search; no visible effect
⁠	U+2060 word joiner	0 px	Blocks a line break and takes no width
­	U+00AD soft hyphen	0 px	Shows a hyphen only if the word breaks there

Only the   in such a run takes up width. The words of the preheader do more work than any filler, so write them as a pair with the subject line.

How MailGraf handles non-breaking spaces

The Preview text you enter on a campaign's Setup step goes into a hidden block at the top of the email. MailGraf escapes it as plain text and adds no filler after it, so type words only.

Personalisation fields get the same treatment. MailGraf escapes a contact's value before it goes into the HTML, so a field that stores   shows the code.

MailGraf also builds the plain-text version of every send, as the checks before sending explain. We ran its converter on sample HTML. Each   turned into a plain space, and the hidden preview line was left out.

A double-encoded   still came through as  . That fault shows in both versions.

The emails in MailGraf's Ready flows for automations, such as the first email of Welcome email series, open with a starting layout that already ties line endings. The last two or three words of each heading and paragraph are joined with  .

Headings tie at most two words and 18 characters, body text three words and 30 characters. Those limits keep every tied group narrow enough for a 320 px phone.