TL;DR
You convert a page to PDF and the text is wrong. Empty rectangles where Chinese characters were. Arabic letters sitting apart from each other instead of joining. Emoji rendered as monochrome outlines. A brand typeface silently swapped for something generic.
Four distinct failures, four different causes:
| What you see | Cause | Fixable by you? |
|---|---|---|
| □□□ ("tofu") boxes | No font on the system covers those characters | Yes — install a font |
| Arabic/Hebrew disconnected or mis-ordered | Text is images, or the site fights the shaping engine | Partly |
| Emoji lost colour | The PDF viewer, not the PDF | Yes — open it elsewhere |
| Wrong typeface entirely | Webfont didn't load before capture | Yes — reload and wait |
The important structural point: Convert: Web to PDF renders through Chrome's own print engine, so the PDF gets whatever Chrome got. If the text renders correctly in your tab, it will almost always render correctly in the PDF. If it's already broken on screen, the PDF faithfully reproduces the breakage — and that's the first thing to check.
Rule zero: look at the tab first
Before diagnosing anything, look at the page on screen. Is the text correct there?
- Correct on screen, broken in PDF → font embedding or timing. Keep reading.
- Broken on screen too → it's the page or your system, not the conversion. Fixing the page fixes the PDF.
This sounds obvious and it eliminates about half of reported cases. People convert, see boxes, and blame the converter without checking that the boxes were already there.
Failure 1: Tofu (□□□)
What it means
Those empty rectangles are the Unicode replacement glyph. They mean: the character is present in the document, correctly encoded, and no available font has a shape for it. The text isn't corrupted — it's unrenderable.
This is why you can often still select the boxes and paste them somewhere else and get real characters back. Try it. It's a useful confirmation that nothing is actually lost.
Where it bites
- CJK on a Latin-only system. A Western machine with no CJK fonts installed will tofu Chinese, Japanese, and Korean text.
- Rare or historical scripts. Coptic, Gothic, cuneiform, older CJK ideographs outside the common ranges.
- Symbol-heavy technical content. Advanced mathematical operators, obscure currency symbols, box-drawing characters.
- Newer emoji. An emoji added in the last Unicode revision may not exist in your installed emoji font yet.
Why the site looked fine and the PDF doesn't
Because the site was serving a webfont that covered those characters, and the webfont didn't make it into the capture — see Failure 4. Once the webfont drops out, Chrome falls back to system fonts, and if no system font covers the script, you get tofu.
The fix
Install a font that covers the script. Noto is the practical answer — Google's Noto family exists precisely to cover all of Unicode, and it's freely available. Noto Sans CJK covers Chinese, Japanese, and Korean; Noto Sans Arabic, Noto Sans Devanagari, Noto Sans Thai and so on cover the rest.
Once the font is installed, Chrome's fallback chain finds it, the page renders correctly, and so does the PDF.
Platform notes:
- macOS ships with broad CJK coverage (Hiragino, PingFang, Apple SD Gothic Neo) and rarely tofus common CJK
- Windows ships with reasonable CJK coverage but you may need to add the optional language pack for full support
- Linux varies enormously by distribution;
fonts-noto-cjkis usually a package away - ChromeOS generally handles this well out of the box
Failure 2: Arabic, Hebrew, and other RTL scripts
This is the one with the most misdiagnosis, so it's worth being precise.
What correct looks like
Arabic is a connected, bidirectional script. Letters change shape depending on position in a word (initial, medial, final, isolated), and the text runs right-to-left while embedded numbers run left-to-right. Getting this right requires a shaping engine — and Chrome has a good one (HarfBuzz).
What broken looks like, and what each means
Letters correct but sitting apart, not joining: the shaping engine didn't run, or ran on text it couldn't shape. Usually this means the "text" is actually an image, or the site has applied a CSS transform that defeats shaping.
Word order reversed within a line: a bidirectional algorithm problem. Rare in Chrome's own rendering; common when text has been extracted and re-laid-out by an intermediate tool.
Numbers in the wrong place inside a sentence: usually correct behaviour that looks wrong to a Latin-script reader. Arabic embeds LTR runs for numerals; the visual result is legitimately what the standard specifies.
Everything tofu'd: not an RTL problem at all. That's Failure 1 — no Arabic font installed.
Why the browser-extension route matters here
Because Chrome does the shaping, and the PDF captures Chrome's result. A URL-based converter running its own headless renderer on a Linux server may have a completely different font stack and a differently-configured shaping setup — which is exactly how you end up with disconnected Arabic from a service that renders Latin text perfectly.
If the Arabic looks right in your tab, converting locally preserves it.
The genuine limits
Text baked into images. A lot of Arabic-language web content — especially older news sites, forum signatures, and graphics-heavy pages — sets text as images. Those come through as images. There is no OCR in Convert: Web to PDF and no plan to pretend otherwise: the pixels stay pixels, unselectable and unsearchable.
Article Mode and RTL. Readability generally preserves direction correctly, but it rebuilds the DOM. On a page with mixed-direction content or unusual markup, it can occasionally produce a layout that's technically correct and visually surprising. If RTL output looks off in Article Mode, convert in default mode instead.
Failure 3: Emoji lost their colour
What's happening
Colour emoji are not normal glyphs. They're stored as embedded bitmaps or vector layers inside the font, using formats (CBDT/CBLC, sbix, COLR/CPAL) that PDF viewers support inconsistently.
The diagnostic that saves time
Open the same PDF in a different viewer. The most common version of this complaint is: black-and-white in one app, full colour in another. That means the PDF is fine and the viewer isn't.
- Chrome's built-in PDF viewer: generally good
- macOS Preview: generally good
- Adobe Acrobat Reader: good on recent versions, patchier on older ones
- Older enterprise PDF viewers and some document-management previews: frequently monochrome
If the PDF renders in colour anywhere, the emoji are in there.
If it's genuinely monochrome everywhere
The system fell back to a monochrome emoji font at render time. On Linux this is common (fonts-noto-color-emoji is often the missing piece). On Windows and macOS it's unusual.
Failure 4: The wrong typeface
What's happening
Webfonts load asynchronously. The browser renders with a fallback first, then swaps in the real font when the file arrives — the font-display: swap behaviour that's now near-universal because it's better for perceived performance.
Capture during that window and you capture the fallback. Your brand's typeface becomes Arial. Worse, if the fallback lacks glyph coverage the real font had, you also get tofu.
The fix
Genuinely this simple: let the page finish loading. Reload, wait a couple of seconds after the page appears settled, then convert. On a slow connection or a page loading many font weights, give it longer.
You can confirm fonts are done by looking at whether the text visibly reflowed — that little shift as the real font lands. Once it's stopped shifting, you're clear.
The other cause: the font can't be embedded
Some commercial webfonts are licensed in ways that restrict embedding into documents. When a font's embedding permission bits forbid it, the PDF stores a substitute instead. This is a licensing decision by the foundry, not something a converter overrides — and any tool that did override it would be helping you violate a font licence.
The output is still fully correct text. Only the typeface differs.
A decision table
| Symptom | Check first | Fix |
|---|---|---|
| □□□ boxes | Are they boxes on screen too? | Install Noto for that script |
| Boxes only in PDF | Did the webfont load? | Reload, wait, re-convert |
| Arabic letters not joining | Is it selectable text or an image? | If image: nothing to do. If text: convert in default mode |
| Emoji monochrome | Does another PDF viewer show colour? | Use a different viewer |
| Wrong typeface, text correct | Did you convert immediately after load? | Reload, wait 2–3s, convert |
| Text correct but overlapping | — | Reduce scale, or convert in default mode |
| CJK renders but spacing is odd | Is a Latin font being used for CJK? | Install a proper CJK font |
Why local conversion wins on multilingual pages
This isn't a general privacy argument — it's specific to text rendering.
Hosted converters (PDFCrowd, Smallpdf's URL tools, similar services) render on their infrastructure. Their font stack is whatever's installed on those servers. For a Latin-script marketing page, fine. For a page in Thai, Bengali, or Georgian, you're depending on a server you can't inspect having the right fonts — and when it doesn't, you get tofu with no way to diagnose it.
Screenshot-based tools produce an image, which sidesteps every font question and creates a worse one: nothing is selectable or searchable, and a screen reader gets nothing. For a document in a script you can't type, being unable to copy text out is a serious loss.
Convert: Web to PDF uses the fonts on your machine, in your browser, with Chrome's shaping engine. What you see is what you get — and when something's wrong, you can see it's wrong before you convert, which is the whole diagnostic advantage.
Everything runs locally, so this also works on logged-in pages: a Japanese-language account dashboard, an Arabic-language government portal you're signed into, an internal tool in Korean.
Frequently asked questions
Why does my PDF show empty boxes instead of Chinese or Japanese characters?
Those boxes mean no available font contains those glyphs. The text is intact — you can usually select and copy it and get real characters. Install a CJK font (Noto Sans CJK is the free, comprehensive option) and re-convert. If the boxes only appear in the PDF and not on screen, the page's webfont hadn't finished loading when you converted; reload, wait, and try again.
Why is Arabic text in my PDF not joined up?
Arabic letters join contextually, which requires text shaping. If letters appear isolated, the most likely explanation is that what looks like text is actually an image — check by trying to select it. If it is real text and it renders correctly in your browser tab, convert in default mode rather than Article Mode, since rebuilding the DOM can occasionally disturb mixed-direction layout.
Can the extension convert text in images to selectable text?
No. There is no OCR in Convert: Web to PDF. Images of text come through as images — visible in the PDF, but not selectable, searchable, or copyable.
Why did my PDF use a different font than the website?
Almost always a timing issue: webfonts load after initial render, and converting during that window captures the fallback font. Reload the page, wait until text stops shifting, then convert. Less often, the webfont's licence forbids embedding into documents, in which case a substitute is stored — the text is still correct, only the typeface differs.
My emoji are black and white in the PDF. Is the file broken?
Probably not. Colour emoji use font formats that PDF viewers support inconsistently. Open the same file in a different viewer — Chrome's built-in viewer and macOS Preview usually show colour. If every viewer shows monochrome, your system fell back to a monochrome emoji font at render time.
Does converting locally give better results for non-English pages than an online converter?
For font rendering, yes, and for a concrete reason: local conversion uses the fonts and shaping engine already rendering the page in your browser, so what you see on screen is what lands in the PDF. A hosted converter renders with its own server's fonts, which you can't inspect and which may lack coverage for your script.
Does any of this affect whether the PDF text is searchable?
Real text stays real text regardless of which font renders it — selectable, searchable, copyable. The exception is text that was an image to begin with, which stays an image.
Bottom line
Font problems in web-to-PDF are diagnosable, and almost all of them announce themselves before you convert. Look at the tab first.
Tofu means a missing font — install Noto for that script. Disconnected Arabic usually means the text is a picture. Monochrome emoji usually mean the viewer, not the file. A wrong typeface usually means you converted a second too early.
The structural advantage of converting in the browser is that Chrome has already solved the hard parts — shaping, bidirectional layout, fallback chains — and the PDF inherits that work. A server in another country rendering your Bengali page with whatever fonts it happens to have does not.
Convert: Web to PDF is free, local, and produces real PDFs with selectable text in any script your system can render. The site and its full FAQ are available in 14 languages.
Also from us: CineMan AI, which tells you what to watch instead of making you read another catalogue.