GlyphSift
Style TextClean TextInspect UnicodeGuidesCompatibilityAll Tools
Open studio ↘
Home/Guides/Why Copied Underlines Look Different in Each App

Unicode guide

Why Copied Underlines Look Different in Each App

Underline that survives copy-paste is not the underline button from a rich-text editor. It is a combining character added after each letter, and how it looks depends entirely on the font and app that render it.

Written & reviewed by Jack Shi · Last reviewed 2026-09-20

Make it now

Generate it in three steps

  1. 1

    Open the Underline Text Generator and type or paste your text.

  2. 2

    GlyphSift adds the U+0332 combining low line after each letter and digit, leaving spaces and emoji unmarked.

  3. 3

    Copy the result and test it in the destination; if the line looks broken, that is the destination font's rendering, not a text error.

Open the Underline Text Generator →
01

The underline is a combining character

U+0332 COMBINING LOW LINE belongs to the Combining Diacritical Marks block, U+0300–U+036F. Placed after a visible character, it draws a line beneath it and travels with the text when copied.

This is different from an HTML <u> element or an editor's underline setting, which are formatting applied around the text. Those do not survive a paste into a plain-text field, whereas the combining character is part of the text itself.

InputAB
GlyphSift outputA̲B̲

Each letter is followed by U+0332; the underline is encoded in the text.

02

Why it looks connected in one app and broken in another

The destination font decides how the low line is drawn and whether adjacent marks join into a continuous underline. Some fonts extend the stroke across the full character width so it looks unbroken; others draw a shorter stroke, leaving visible gaps between letters.

Spacing, kerning, and the app's text rendering engine also affect the result. The underlying characters are identical everywhere — only the rendering differs — so a broken-looking underline is a display detail, not corrupted text.

03

Where combining underline is left off

Stacking a combining low line on emoji, spaces, or lone marks tends to render as a broken box or a stray stroke, so it is usually skipped there. Precomposed accented letters may also be left without an added mark to avoid double-drawing.

Because the effect depends on rendering and can reduce searchability, avoid combining underline for essential information, and test the destination before relying on it.

Try the behavior

Related tools

styleUnderline Text Generator

Add a combining underline (U+0332) to letters and digits so text stays underlined after copying into plain-text fields.

Open tool →
inspectUnicode Character Inspector

Inspect code points, offsets, UTF-8 bytes, scripts, categories, and risk flags character by character.

Open tool →
styleStrikethrough Text Generator

Add a Unicode combining stroke over each character to create copyable strikethrough text.

Open tool →

FAQ

Frequently asked questions

Why does my underlined text look broken in some apps?
The combining low line is drawn by the destination font. Some fonts join the strokes into a continuous underline; others draw shorter strokes with gaps. The underlying text is the same everywhere — only the rendering differs.
Is this the same as the underline button?
No. An editor's underline is formatting that is lost in plain-text fields. This adds the U+0332 combining character to the text, so the underline is copied along with it.
Why are emoji and spaces not underlined?
Stacking a combining low line on emoji, spaces, or lone marks often renders as a broken box, so it is left off to keep the result readable.

Primary standards

References

  • The Unicode Standard, Version 17.0
  • Combining Diacritical Marks (U+0300–U+036F)
GlyphSiftStyle it. Clean it. Check it. Paste with confidence.
Style mapGuidesAboutAuthorContactPrivacyTermsEditorial

Independent copy-paste text tools · hello@glyphsift.com · Platform claims require evidence

Static Unicode maps target Unicode 17.0. Segmentation and normalization use the runtime's Unicode data.