DEV Community: Mahmoud Ibrahim — Confileo

"Invisible text is not empty: the five Unicode blanks apps actually keep"

Mahmoud Ibrahim — Confileo — Wed, 02 Sep 2026 07:09:03 +0000

Every few weeks someone asks the same question in a different costume: how do I send an empty message on WhatsApp, how do I make my Free Fire name invisible, why does my Instagram bio lose its blank lines. The answer is the same each time, and it is not a trick inside any of those apps. It is Unicode.

A space is not a character. To an app, it is a separator.

When you type a name, a message or a bio, the app trims it before saving. Leading and trailing whitespace goes, runs of spaces collapse, and a field that contains only spaces becomes an empty string. Then the validation runs: empty name, empty message, rejected.

So "invisible text" cannot be made of spaces. It has to be made of characters that render as nothing but are not whitespace to the trimming code. Unicode has several, and they were never designed for this. Each exists for a real typographic or scripting reason, which is exactly why every app treats them differently.

The five that matter, and what each was for

Character	Code point	Why it exists	Who keeps it
Hangul Filler	`U+3164`	A placeholder in Korean syllable composition — a "letter" that draws nothing	Game nickname fields (Free Fire, PUBG Mobile), Instagram name and bio, TikTok nickname
Braille Pattern Blank	`U+2800`	The braille cell with no dots raised — a printable glyph that is empty	WhatsApp, Telegram and Discord messages, Instagram comments
Zero-Width Space	`U+200B`	A line-break opportunity with no width, for scripts without spaces	X posts, Apple Notes, HTML; stripped by most chat apps
Invisible Separator	`U+2063`	Marks an invisible boundary between items (think matrix indices)	Facebook and Messenger
Hair Space	`U+200A`	The thinnest typographic space	Word, Google Docs, email

The pattern is not random. Hangul Filler is a letter (category Lo), so a name validator that asks "does this contain at least one letter?" says yes. Braille Blank is a symbol (So) — printable, so a "message must not be empty" check passes. Zero-Width Space is a format character (Cf), and format characters are the first thing a sanitiser strips, which is why it fails in WhatsApp and works in a text editor.

If you want to see the categories yourself:

for (const ch of ['ㅤ', '⠀', '', '⁣', ' ']) {
  const cp = ch.codePointAt(0).toString(16).toUpperCase().padStart(4, '0');
  console.log(`U+${cp}`, /\p{L}/u.test(ch) ? 'letter' : /\p{S}/u.test(ch) ? 'symbol' : /\p{Cf}/u.test(ch) ? 'format' : /\p{Zs}/u.test(ch) ? 'space' : 'other');
}
// U+3164 letter · U+2800 symbol · U+200B format · U+2063 format · U+200A space

Why an invisible name breaks after an update

A game that once accepted U+3164 and now rejects it did not "patch invisible names". Somebody added a Unicode normalisation or a category filter to the name validator — usually to stop impersonation, because two names that look identical but differ by an invisible character are a moderation nightmare. The moment a validator runs NFKC normalisation, U+3164 becomes U+1160 (Hangul Jungseong Filler) or is dropped entirely, and U+FFA0 (the halfwidth form) folds into the same thing.

That is why any honest invisible-text tool offers several characters instead of one, and says which app each survives. It is also why "test on your own account before spending a rename card" is the only advice that stays true across updates.

Detecting it is trivial, which is the point

Invisible does not mean hidden. Paste the text into anything that counts characters and the count gives it away:

const INVISIBLE = new Set([0x200B, 0x200C, 0x200D, 0x2060, 0xFEFF, 0x2800, 0x3164, 0xFFA0, 0x2063, 0x200A, 0x00A0]);
const report = (s) => {
  let invisible = 0;
  for (const ch of s) if (INVISIBLE.has(ch.codePointAt(0))) invisible++;
  return { total: [...s].length, invisible };
};
report('abㅤ⠀'); // { total: 4, invisible: 2 }

Two details that bite: iterate with for…of, not .length — .length counts UTF-16 code units, so an emoji is 2 and a family emoji is 11, and your "invisible" count drifts. And normalise after counting if you must normalise at all; s.normalize('NFKC') removes the very characters you are trying to find.

The other kind: text that carries a message nobody can see

There is a second, unrelated trick that gets called "invisible text" too. Zero-width characters come in pairs that a program can tell apart — U+200B and U+200C — so a string of them can carry bits. Encode each byte of a message as eight zero-width characters, wrap the run in a visible carrier so the chat app accepts it, and the recipient pastes the "empty" message back into the same page to read it. It is steganography, not encryption: anyone with the decoder reads it. The ghost text page does exactly that, and the newer invisible text page is the plain-blank version — one tap copies the character an app keeps, and a checker box tells you whether what you pasted really contains one.

Both run in the browser. There is nothing to upload; the "tool" is a clipboard write of a string the page already holds.

Practical summary

Blank message in WhatsApp, Telegram, Discord: U+2800.
Blank name or bio line in Instagram, TikTok, Free Fire, PUBG: U+3164 (fallback U+FFA0).
Blank post on X or a hidden line in Notes: U+200B.
Facebook / Messenger: U+2063. Documents and email: U+200A.
Nothing works in a field that validates against [a-z0-9._] — Instagram and Discord usernames — and no tool can change that.

If you maintain a name field and want to stop this: normalise with NFKC, then reject anything that is empty after removing \p{Cf}, \p{Zs} and the two Hangul fillers. Say so in the error message, because "invalid name" sends people straight back to the tools above.

Unicode's bold alphabet has holes in it, and every text generator falls in

Mahmoud Ibrahim — Confileo — Fri, 28 Aug 2026 04:13:52 +0000

If you have ever built a "fancy text" generator — the things people paste into
Instagram bios and Discord names — you have written this function:

// Looks right. Is wrong.
const toBold = text => text.replace(/[A-Za-z]/g, ch => {
  const c = ch.charCodeAt(0);
  return c <= 90
    ? String.fromCodePoint(0x1D400 + (c - 65))   // A-Z
    : String.fromCodePoint(0x1D41A + (c - 97));  // a-z
});

Map A onto U+1D400, add the offset, done. It works. You test it with
"Hello World", get 𝐇𝐞𝐥𝐥𝐨 𝐖𝐨𝐫𝐥𝐝, and ship it.

Then someone types their name in cursive and gets ☐.

The block is not contiguous

The Mathematical Alphanumeric Symbols block, U+1D400–U+1D7FF, holds about a
dozen styled Latin alphabets: bold, italic, bold italic, script, bold script,
fraktur, double-struck, sans-serif, monospace, and the digit sets.

It reads like a clean set of 26-letter runs. It is not. When the block was
encoded, some of those letters already existed in the Letterlike Symbols
block, U+2100–U+214F, because mathematicians had been using them as named
constants for decades — ℋ for the Hamiltonian, ℒ for the Lagrangian,
ℝ for the reals. Unicode does not encode the same character twice. So rather
than duplicate them, it left those slots in the new block permanently
unassigned.

Five alphabets have gaps. Here is the complete set:

Style	Missing letters	Where Unicode actually put them
Script	B E F H I L M R, e g o	ℬ ℰ ℱ ℋ ℐ ℒ ℳ ℛ, ℯ ℊ ℴ
Fraktur	C H I R Z	ℭ ℌ ℑ ℜ ℨ
Double-struck	C H N P Q R Z	ℂ ℍ ℕ ℙ ℚ ℝ ℤ
Italic (serif)	h	ℎ (Planck's constant)

Every one of those is a hole your arithmetic falls into. 𝒜 + 1 is not ℬ, it
is U+1D49D, which is nothing at all. Your users see tofu, and only for certain
letters, which is why this survives testing: "Hello" breaks in script and
fraktur, "World" does not.

The fix is a lookup, not cleverness

There is no formula. The gaps are historical accident, so the only correct
implementation is an explicit exception table consulted before the arithmetic:

type Style = {
  upper?: number; lower?: number; digit?: number;
  holes?: Record<string, string>;
};

const HOLES_SCRIPT = {
  B: 'ℬ', E: 'ℰ', F: 'ℱ', H: 'ℋ', I: 'ℐ', L: 'ℒ', M: 'ℳ', R: 'ℛ',
  e: 'ℯ', g: 'ℊ', o: 'ℴ',
};

function styleChar(ch: string, s: Style): string {
  if (s.holes?.[ch]) return s.holes[ch];       // check the table FIRST
  const c = ch.charCodeAt(0);
  if (c >= 65 && c <= 90  && s.upper !== undefined) return String.fromCodePoint(s.upper + c - 65);
  if (c >= 97 && c <= 122 && s.lower !== undefined) return String.fromCodePoint(s.lower + c - 97);
  if (c >= 48 && c <= 57  && s.digit !== undefined) return String.fromCodePoint(s.digit + c - 48);
  return ch;                                    // pass everything else through
}

The test that catches it is a pangram, checked for the reserved codepoints
rather than eyeballed:

const RESERVED = new Set([
  0x1D455, 0x1D49D, 0x1D4A0, 0x1D4A1, 0x1D4A3, 0x1D4A4, 0x1D4A7, 0x1D4A8,
  0x1D4AD, 0x1D4BA, 0x1D4BC, 0x1D4C4, 0x1D506, 0x1D50B, 0x1D50C, 0x1D515,
  0x1D51D, 0x1D53A, 0x1D53F, 0x1D545, 0x1D547, 0x1D548, 0x1D549, 0x1D551,
]);

const out = apply('How vexingly quick daft zebras jump', style);
const bad = [...out].filter(c => RESERVED.has(c.codePointAt(0)));
console.assert(bad.length === 0, style.id, bad);

Eyeballing does not work, because ☐ is what a missing font looks like too.
Checking the codepoints tells you which of the two you have.

Three more traps in the same neighbourhood

Iterate codepoints, not code units. Every character you are producing is
astral-plane — above U+FFFF, so two UTF-16 code units. The moment your input
contains an emoji, or someone pastes your own output back in, for (let i = 0; i < text.length; i++) splits a surrogate pair and you emit garbage. for…of
and [...text] both iterate by codepoint. Use them.

Seed your zalgo. Glitch text works by stacking combining diacritics —
U+0300–U+036F — on each letter, and there is no limit on how many can stack.
The obvious implementation reaches for Math.random(). Do not: if the output is
rendered reactively, every keystroke re-randomises the whole string, so the
text visibly crawls while the user types and the thing they copy is not the
thing they were looking at when they decided they liked it. Derive the seed from
the input and run a tiny PRNG:

let state = seed | 0 || 1;
const next = () => {
  state ^= state << 13; state ^= state >>> 17; state ^= state << 5;
  return (state >>> 0) / 4294967296;
};

Make upside-down text an involution. Flipping is two operations: substitute
each character for its turned twin (a → ɐ, U+0250), then reverse the
string, because a genuinely rotated line reads from what was its end. Skip the
reversal and you get mirror writing, which is the most common bug in these
tools. But there is a subtler one: half your users arrive with text that is
already upside down and want it turned back. If your table only maps a → ɐ,
pasting ɐ back in leaves it untouched. Fill the reverse direction from the
forward table and the same function does both jobs:

for (const [k, v] of Object.entries({ ...FLIP })) {
  if (!(v in FLIP)) FLIP[v] = k;   // only fill gaps; hand-written pairs win
}

The part nobody tells users

Styled Unicode is worse for accessibility and for search, and it is worth saying
so in the UI rather than leaving people to find out.

A screen reader does not read 𝗯𝗼𝗹𝗱 as "bold". It reads it as "mathematical
bold small b, mathematical bold small o, mathematical bold small l,
mathematical bold small d" — because that is what those characters are named.
Search engines do not match 𝘀𝗵𝗼𝗲𝘀 to a search for shoes either.

That makes these styles genuinely good for a decorative username or one accent
word, and genuinely bad for a whole bio, a business name people need to find, or
anything that has to be read aloud. Most generators do not mention it. It costs
one sentence and it is the difference between a tool and a trap.

Working reference

Every finding here came out of building the text tools on
Confileo — 26 styles, the
full holes table, seeded glitch and a two-way flip, all client-side. The
upside-down one is the quickest
way to check the involution claim: paste its output back into its own box and
you should get your original line, character for character.

If you are building your own, the short version is: check the table before you
do the arithmetic, iterate by codepoint, seed anything random, and tell your
users what the output costs them.

The Arabic PDF bug was never in my code — it was the library version

Mahmoud Ibrahim — Confileo — Wed, 19 Aug 2026 00:31:04 +0000

In my last post I wrote about why Arabic comes out of PDF extraction in reverse word order. A commenter asked the obvious follow-up question, and it is the one I want to answer properly:

Did you end up running a full bidi pass, or approximating with run-level heuristics? That mixed-direction case is usually where the heuristics fall apart.

Neither. And that turned out to be the whole point.

What I thought the problem was

The naive mental model goes like this: the PDF stores glyphs in the order they were painted, painting for RTL text runs right-to-left, so extraction hands you a line that reads last-word-first. Therefore you must reconstruct logical order yourself — which means implementing the Unicode Bidirectional Algorithm (UAX #9) over the positioned glyphs.

That is a genuinely hard thing to do, for a reason the commenter named exactly: UAX #9 needs a base paragraph direction, and the PDF never stored one. You have to infer it from the script of the runs. Get it wrong on a line like المبلغ: 128 SAR and your "fix" flips the Latin and the digits too. You have turned one bug into two, and the second one only shows up on invoices and CVs — which is to say, on almost every document a user actually cares about.

I wrote a chunk of that logic. It half worked, which is worse than not working, because half-working code makes you write more of it.

What the problem actually was

Then I ran the same PDF through the same code on a different machine and got correct output.

The extraction library was handing me visual order on one machine and logical order on the other. Same file, same code, different dependency version.

LibreOffice. Version 7.1 (2021), which is what a lot of stable server distributions still ship, reverses Arabic on PDF import — it gives you paint order. A modern LibreOffice extracts logical order directly. The server was on 7.1. My laptop was not.

PyMuPDF. Same class of bug, different library. Below 1.24, Arabic comes back visual and reversed. From 1.24 onward it comes back logical.

So the correct amount of bidi reconstruction code is zero. Both libraries already do it, in the versions where they do it. Everything I had written was scrambling text that had already arrived in the right order, on exactly the machines where the library was correct — which is why it looked like an intermittent bug and cost me months.

The trap that hid it for weeks

Here is the part worth stealing, because it is what made this so hard to see.

The pipeline had two engines: LibreOffice as primary, and pdf2docx (which sits on PyMuPDF) as a fallback. Sensible design. Then PyMuPDF 1.26.5 removed Rect.get_area(), a method pdf2docx 0.5.8 still calls:

# pdf2docx 0.5.8, somewhere in layout analysis
if bbox.get_area() / page_area > threshold:

AttributeError. The fallback engine crashed on import-time-adjacent code paths, the orchestrator caught it, and everything silently fell through to the other engine.

Nothing was logged as broken because nothing was broken from the caller's point of view — output came back, tests passed, files converted. But I could no longer tell which engine had produced any given file, so I was debugging Arabic ordering against an engine that had not run in weeks.

The fix was a two-line shim rather than pinning PyMuPDF backwards:

def _ensure_pdf2docx_compat():
    """pdf2docx 0.5.8 calls Rect.get_area(), removed in PyMuPDF 1.26.
    Restore it rather than pinning back to a version that returns visual order."""
    import fitz
    for cls in (fitz.Rect, fitz.IRect):
        if not hasattr(cls, 'get_area'):
            cls.get_area = lambda self: abs(self.width * self.height)

The general lesson: a silent fallback is a debugging tarpit. If your orchestrator can switch engines without telling you, the first thing to add is not a retry, it is a log line naming which engine produced the output.

One infrastructure footgun on the way

Upgrading LibreOffice on a server usually means dropping a newer build somewhere and repointing the binary:

ln -sf /opt/libreoffice26.2/program/soffice /usr/bin/soffice

ln -sf will happily create that symlink when the target does not exist yet. You get a dangling link, LibreOffice stops working entirely, and the error you get back has nothing to do with symlinks. Confirm the binary is there before repointing, and restart the service afterwards — a long-running process that resolved soffice at startup will keep using the old path until it does.

What is left after you delete the reversal code

Not nothing, but much less than you would expect. Two things still need doing.

Normalise presentation forms. Some PDFs encode Arabic using the Unicode presentation-form blocks (U+FB50–FDFF, U+FE70–FEFF) — the pre-shaped initial/medial/final glyph variants — instead of base letters. The text is technically correct and will look fine, but it is not searchable, will not match a query typed normally, and behaves badly in Word. NFKC folds them back:

import unicodedata
text = unicodedata.normalize('NFKC', text)

Note that this is the only normalisation you want here. NFKC is safe for this because the presentation forms have canonical decompositions to their base letters. Do not go further and start stripping diacritics; you will damage Quranic text and vowelised teaching material.

Mark direction in the output format. For DOCX, logical order in the string is not enough — Word needs to be told the run is RTL, or it renders correctly-ordered text with left-aligned paragraph flow, which looks subtly wrong to a native reader:

<w:rPr>
  <w:rtl/>
  <w:rFonts w:cs="Arabic Typesetting"/>
</w:rPr>
<w:pPr>
  <w:bidi/>
</w:pPr>

w:bidi on the paragraph, w:rtl on the run, and a complex-script font via w:cs — miss the last one and Word substitutes something that breaks the cursive joins.

The takeaway

If you are debugging reversed RTL text in an extraction pipeline, check your library versions before you write a single line of bidi logic. The odds are high that the layer below you already solved it and you are about to un-solve it.

And add a version matrix to your i18n tests. Not a version floor — a matrix. This class of bug is invisible in a test suite that only ever runs one version of the thing doing the extracting, and it will reappear the day someone deploys to a distribution that pins an older package.

I write these up as I hit them while building Confileo, a free PDF toolkit where Arabic support is the point rather than an afterthought. If you have a PDF that still comes out wrong, I would genuinely like to see it — the interesting bugs are always in the files, not in the spec.

Why Arabic text comes out backwards when you extract it from a PDF (and how to fix it)

Mahmoud Ibrahim — Confileo — Sat, 04 Jul 2026 00:15:53 +0000

If you've ever built a feature that extracts text from PDFs, an Arabic-speaking user has probably filed this bug: "the words come out in reverse order." Not the letters — the words. Every line reads last-word-first.

I spent the better part of a year fixing this class of bugs while building Confileo, a free PDF toolkit with first-class Arabic support. Here's what's actually going on, because almost every explanation online is wrong or incomplete.

The four distinct failure modes

People say "Arabic breaks" as if it's one bug. It's four:

1. Visual vs logical order (the reversed-words bug)

A PDF doesn't store text the way a Word file does — it stores positioned glyph runs: "paint these shapes at these coordinates." For left-to-right scripts, the paint order happens to match the reading order, so naive extraction works by accident.

Arabic is right-to-left. Many PDF generators emit the glyph runs in visual order — the order they appear on screen, left to right. A naive extractor concatenates the runs as stored and produces every line word-reversed. The text was never "reversed" in the file; your extractor just assumed paint order == reading order.

Fix: reconstruct logical order using glyph positions + the Unicode Bidirectional Algorithm (UAX #9), not the content-stream order. Libraries like PyMuPDF already return text in logical order — a common mistake is "fixing" that output by reversing it again, which is how you get double-reversed text. Rule of thumb: never reverse Arabic yourself. If it looks backwards, your rendering layer lacks bidi support; the data is usually fine.

2. Disconnected letters (the ransom-note bug)

Arabic letters are contextual: ع renders differently in initial, medial, final and isolated positions, and letters join. That joining is applied at render time by a shaping engine (HarfBuzz being the standard).

If any step of your pipeline round-trips text through a non-shaping renderer — a canvas library, a barebones PDF writer, an image caption filter — you get isolated forms: م ر ح ب ا instead of مرحبا. (Fun fact: ffmpeg burns subtitles correctly only because libass links HarfBuzz + FriBidi. Strip those and Arabic subtitles shatter.)

Fix: only render Arabic through stacks that do real shaping. If you're generating PDFs headlessly, Chromium/Puppeteer shape correctly; many lightweight PDF writers do not.

3. Font substitution (the hollow-boxes bug)

Your server converts a document referencing a font it doesn't have. The substitution fallback has no Arabic glyphs → tofu boxes. This is purely an ops problem: conversion servers get provisioned with Latin fonts only.

Fix: install a proper Arabic set (Noto Naskh Arabic, Amiri, Cairo) on every box that renders documents, and configure fontconfig so substitution prefers them.

4. Scanned PDFs (the empty-output bug)

A scanned PDF has no text layer at all — each page is a bitmap. Extraction returns nothing, or worse, your pipeline silently emits an "editable" file full of images. The only real answer is OCR, and generic OCR models trained mostly on Latin do poorly on connected Arabic script; use one with genuine Arabic training (PaddleOCR and Tesseract's ara traineddata are workable starting points).

Numbers and mixed text: the boss level

Dates like 2024/05/13 inside an RTL sentence follow their own bidi embedding rules — digits are LTR within an RTL context. Get the algorithm wrong and "من 2020 إلى 2024" turns into "من 2024 إلى 2020", silently corrupting the meaning. This is why you implement UAX #9 (or use a library that does) instead of hand-rolling direction logic.

Try it / steal the approach

I've put all of this into production converters you can poke at for free — Arabic Word → PDF (shaping + bundled fonts) and Arabic PDF → Word (logical-order extraction). No signup needed, so they're easy to use as a reference for what correct output should look like when testing your own pipeline.

If you're dealing with the same class of bugs in Hebrew or Farsi — same four failure modes, same fixes. Questions welcome in the comments; I've probably hit whatever edge case you're stuck on. 🐪