Why Non-Latin Text Breaks in PDF Watermarks — the Limits of Built-in Fonts
Typing a Korean word like "대외비" (confidential) into a PDF watermark tool and getting a few empty boxes (□) in the output is not rare. It's a structural limitation many tools that draw text onto PDFs on the fly in the browser run into, and the cause is in the PDF specification itself.
1. What the PDF standard's 14 base fonts are
The PDF specification (ISO 32000) defines 14 "Standard 14 Fonts" — Helvetica, Helvetica-Bold, Times-Roman, Courier, and so on. What's special about these fonts is that a PDF file doesn't have to carry their font data at all — the spec itself guarantees that every viewer that opens a PDF (Acrobat, browser built-in viewers, printer drivers) carries these 14 fonts natively. That keeps file size small and means no worry about the font breaking wherever it's opened.
2. The problem: these 14 fonts are all Latin-only
The standard 14 fonts are based on encoding tables called WinAnsiEncoding and MacRomanEncoding, and the glyphs (actual drawable character shapes) in those tables are entirely Western European Latin letters, digits, and symbols. Hangul (11,172 Korean syllables), Han characters, and Kana glyphs simply don't exist inside these 14 fonts. So when you put non-Latin text into watermark text, the renderer ends up in a "there's no glyph for this code" state and displays empty boxes or broken characters — the font isn't damaged, there's just no way to draw it.
3. The code this tool actually uses
This site's PDF watermark tool draws text directly onto each page with the pdf-lib library, and the actual source code uses only a standard font, like this:
const font = await pdfDoc.embedFont(StandardFonts.HelveticaBold);With no code to load a separate font file, it uses only Helvetica-Bold, built into the PDF standard. The tool's own FAQ also states that "Korean watermarks are not supported."
4. The fix: custom font embedding
To actually render non-Latin text, you have to embed a whole TTF/OTF font file containing those glyphs — Noto Sans KR, NanumGothic, and the like — into the PDF. In the pdf-lib ecosystem this requires the separate @pdf-lib/fontkit library: register it with pdfDoc.registerFontkit(fontkit), then embed the actual font file (bytes) with pdfDoc.embedFont(fontBytes), and only then does the PDF become a self-contained file that carries the glyphs itself and opens correctly on any device. This has a trade-off — more code and more file size than using a standard font.
5. Practical approach
- When using this tool: use a Latin word for the watermark — CONFIDENTIAL, DRAFT, SAMPLE — which displays perfectly with the standard font.
- If you must have a non-Latin watermark: find a tool that explicitly states it supports font embedding for that script, or use a desktop PDF editor (Acrobat, etc.).
- Other scripts (Chinese, Japanese) follow the same principle: the standard 14 fonts have the same limitation for CJK characters generally.
Frequently Asked Questions
Q. Can I put Korean (or other CJK) text into this watermark tool?
A. No. It uses only the PDF standard built-in font (Helvetica-Bold), which has no CJK glyphs, so those characters show as empty boxes or broken characters. Use a Latin word instead.
Q. Why didn't the tool include a CJK font from the start?
A. Embedding a font file is a trade-off that increases code complexity and file size. Using only the standard 14 fonts means the tool runs light and fast with no extra file loading, at the cost of supporting Latin characters only.
Q. Other PDF tools handle Korean — why the difference?
A. Those tools implement the extra step of embedding a CJK font file into the PDF using a library like fontkit. It's not a feature every PDF generation tool supports by default — it has to be implemented separately.
Q. Can the characters disappear entirely instead of showing an empty box?
A. It depends on the library and configuration. When it hits an unsupported glyph, an implementation may throw an encoding error, silently skip it, or substitute an empty box — each does it differently.