Fonts Look Wrong in Exported PDF? Embedding Fix
Why Your PDF Suddenly Looks Like a Different Document
You spend an hour perfecting a report in Google Docs or a presentation in PowerPoint, export it to PDF, and then open the file on a colleague's machine — only to find that your carefully chosen Montserrat headings have been swapped out for Times New Roman, or worse, replaced by a blocky fallback font that breaks your entire layout. Columns shift. Line breaks appear in the wrong places. The document looks like it was assembled by someone who has never heard of design. This happens because PDF files can either reference a font by name (and hope the reader's computer has it installed) or embed the actual font data directly inside the file. When a font is referenced but not embedded, the PDF viewer substitutes whatever it considers the closest match. Adobe Acrobat uses a substitution engine called Multiple Master that does a reasonable job, but Preview on macOS, Chrome's built-in PDF viewer, and many mobile readers are far less forgiving. They'll grab the nearest system font and move on. The problem is especially common with custom or commercial fonts — anything that isn't Arial, Times New Roman, Helvetica, or the handful of other 'PDF-safe' faces that have been bundled with operating systems for decades. If you used a Google Font, a purchased typeface from MyFonts, or a brand font your company licensed, there is a real chance it isn't embedded in your exported PDF. The fix exists, but it requires knowing where to look in the software you're using to create or convert the file — and understanding what CocoConvert can and can't do to help.
How to Check Whether Fonts Are Actually Embedded
Before changing any settings, confirm that missing embedding is actually the problem. Open your PDF in Adobe Acrobat Reader (free) and go to File → Properties → Fonts tab. Every font used in the document will be listed, along with its type and — critically — whether it is 'Embedded' or 'Embedded Subset.' Both of those statuses are fine. If you see a font listed with no embedding status at all, or with the word 'Substituted' next to it, that font is not embedded and will look wrong on machines that don't have it installed. If you don't have Acrobat, you can use the free online tool PDFCandy or open the PDF in a text editor and search for the string '/FontDescriptor' — each embedded font will have one of these blocks. It's crude, but it works in a pinch. Another quick test: open the PDF on a second device that definitely does not have your custom font installed — an Android phone, a public library computer, or a fresh virtual machine. If the font looks different there than it does on your main machine, the font is not embedded. One more thing worth checking: the file size. A PDF with embedded fonts will be noticeably larger than one without. If you exported a 20-page document with four custom fonts and the PDF is only 180 KB, that's a strong signal the fonts didn't make it in. A properly embedded version of the same document might be 600 KB to 1.5 MB depending on how many glyphs are included. Font data isn't free — it adds weight, and that weight is actually a good sign.
Fixing Embedding at the Source: Word, Google Docs, and InDesign
The most reliable place to fix font embedding is in the application where you created the document, before conversion ever happens. **Microsoft Word (Windows):** Go to File → Options → Save. Near the bottom of the dialog, check 'Embed fonts in the file.' You'll also see two sub-options: 'Embed only the characters used in the document' (which reduces file size by including only the glyphs that actually appear) and 'Do not embed common system fonts' (which skips Arial, Times New Roman, etc. to save space). Both sub-options are worth enabling for most use cases. Once the font is embedded in the .docx, exporting to PDF via File → Export → Create PDF/XPS should carry the font data through. **Microsoft Word (Mac):** The Save dialog doesn't have the font embedding checkbox on macOS — this is a known limitation. Your best workaround is to use File → Print → PDF (via the system print dialog) or install a PDF printer driver like PDF995. Alternatively, open the file in the Windows version of Word, embed the fonts there, save the .docx, and then export. **Google Docs:** Google Docs does not give you direct control over font embedding. When you use File → Download → PDF Document, Google's servers handle the rendering, and they generally embed fonts from the Google Fonts library correctly. However, if you're using a font you uploaded yourself via a browser extension (like 'Font Changer'), those fonts will not be embedded — Google's export pipeline has no access to them. Stick to native Google Fonts for any document you plan to export as PDF. **Adobe InDesign:** Go to File → Export → Adobe PDF. In the export dialog, select the 'Output' panel on the left. Under 'Color Conversion,' make sure you're using a PDF/X standard (PDF/X-1a or PDF/X-4 are both solid choices for print; PDF/X-4 supports transparency). InDesign embeds all fonts by default when using these standards. If you're exporting to standard PDF, check the 'Marks and Bleeds' and 'Advanced' panels — there's no single 'embed fonts' checkbox because InDesign always embeds unless a font's license explicitly prohibits it, in which case InDesign will warn you during export.
What CocoConvert Does During Conversion
When you upload a file to CocoConvert — say, a .docx or a .pptx — and convert it to PDF, the service renders the document on the server side and generates a new PDF from that rendering. This means the output quality depends heavily on which fonts are available on CocoConvert's rendering servers. CocoConvert's servers have the full Google Fonts library installed, all standard Microsoft Office fonts (Arial, Calibri, Cambria, Times New Roman, and the rest of the Office font set), and a selection of common open-source typefaces. If your document uses any of those fonts, they will be embedded correctly in the output PDF. Here's where we have to be straight with you: if your document uses a commercial font that you purchased and installed on your local machine — something like Proxima Nova, Brandon Grotesque, or a custom brand typeface — CocoConvert does not have that font. The server will substitute a fallback, and your PDF will look wrong. No cloud conversion service can legally install every commercial font in existence; that would violate the font licenses. The workaround for this situation is to embed the font in the source file before uploading (see the previous section on Word's embed option), or to flatten the document to outlines in a tool like Illustrator or Affinity Publisher before converting. When text is converted to outlines, it becomes vector shapes — no font data is needed, and the appearance is locked in permanently. The tradeoff is that the text becomes unsearchable and unselectable in the final PDF, which matters if accessibility or copy-pasting is important to your readers. For most standard business documents using system or Google fonts, CocoConvert will handle embedding correctly without any extra steps on your end.
The Subset vs. Full Embed Question
When a PDF embeds fonts, it has two options: embed the entire font file, or embed only the subset of glyphs that actually appear in the document. Subsetting is almost always the right choice, and it's what CocoConvert does by default. Here's a concrete example of why it matters: a complete copy of a typeface like Noto Sans (which supports dozens of scripts) can be 500 KB or more per weight. If your document only uses the Latin alphabet and a handful of punctuation marks, you're using maybe 200 of the font's 2,000+ glyphs. Subsetting embeds only those 200 glyphs, which might add just 40–60 KB to your PDF instead of 500 KB. The one scenario where full embedding is preferable is when the PDF will be edited after the fact — for example, if a print shop needs to make last-minute text corrections. With a subset, the editor might not have access to the glyphs needed for their changes, because those characters weren't in the original document and therefore weren't embedded. If you're sending a file to a commercial printer, ask them whether they want full embedding or subsetting; most modern print workflows handle subsetting fine, but it's worth confirming. In Acrobat Pro, you can re-embed or re-subset fonts after the fact using the Preflight tool (Tools → Print Production → Preflight → PDF Fixups → 'Embed missing fonts'). This is useful if you received a PDF from someone else that has substitution problems and you need to fix it without going back to the source file. Acrobat will attempt to embed fonts from your local system — so if you have the font installed, it can patch the PDF. CocoConvert doesn't offer this specific repair workflow, but Acrobat Pro or Enfocus PitStop are the right tools for that job.
Font Licensing and Embedding Restrictions
Not every font can legally be embedded in a PDF, and some fonts are technically restricted from embedding even when you own a license. This is controlled by a flag inside the font file itself called the 'fsType' field (or 'Embedding' flag in OpenType). There are four possible values: - **Installable (0):** The font can be embedded and the recipient can install it. Most open-source fonts use this. - **Editable (8):** The font can be embedded and the document can be edited using that font. - **Print and Preview (4):** The font can be embedded for viewing and printing, but the PDF cannot be edited in a way that modifies text in that font. - **No Embedding (2):** The font cannot legally be embedded at all. You can check a font's embedding permissions using a free tool called 'Font File Analyzer' or by looking at the font's metadata in Typeface (macOS) or Font Book. If a font has the 'No Embedding' flag set, Acrobat and InDesign will refuse to embed it and will warn you. Some older commercial fonts from the 1990s and early 2000s have this restriction; most modern fonts do not. If you're hitting this restriction, your options are: contact the font vendor and ask for an embedding-licensed version (some vendors sell these separately), convert text to outlines as described earlier, or switch to a similar open-source font. Google Fonts and Font Squirrel both host fonts with permissive licenses that explicitly allow PDF embedding. If brand consistency is critical, a designer can often find a Google Font that closely matches a restricted commercial face — not identical, but close enough for most business documents.
A Practical Checklist Before You Export
Running through a quick checklist before you hit export can save a round-trip of confusion, especially when the PDF is going to a client, a printer, or a regulatory body that won't appreciate a garbled font. **1. Identify every font in your document.** In Word, use Find & Replace with 'More' options expanded to search by font. In InDesign, go to Type → Find Font for a complete list. In Google Docs, there's no built-in audit tool — you'll need to scan manually or use a script. **2. Check each font's origin.** Is it a system font? A Google Font? A purchased commercial font? Anything in the last category needs special attention. **3. Enable font embedding in your source application** before exporting, using the paths described earlier in this article. **4. If uploading to CocoConvert,** verify that all fonts in your document are either system fonts, Google Fonts, or already embedded in the source file. If you have commercial fonts that aren't embedded, embed them in Word first, or convert text to outlines in Illustrator or Affinity Publisher. **5. After export, open the PDF's Font Properties** in Acrobat Reader and confirm every font shows 'Embedded' or 'Embedded Subset.' **6. Do a cross-device check** — open the PDF on a phone or a computer where your custom fonts are definitely not installed. What you see there is what everyone else will see. Font embedding problems are almost always solvable, but they require catching the issue before the file leaves your hands. Once a PDF is distributed without embedded fonts, you can't force every reader's device to display it correctly — you can only fix the source and redistribute. Build the verification step into your workflow and you'll stop discovering these problems after the fact.