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. Suddenly, your carefully chosen Montserrat headings are Times New Roman. Or worse, some blocky fallback font has broken your entire layout. Columns are shifting. Line breaks are in the wrong places. It looks like a design-by-ransom-note. What went wrong? PDF files can either reference a font by name—hoping the reader's computer has it installed—or they can embed the actual font data right inside the file. When a font is just referenced but not embedded, the PDF viewer substitutes whatever it considers the closest match. While Adobe Acrobat's substitution engine (Multiple Master) does a reasonable job, other viewers are brutal. Preview on macOS, Chrome's built-in viewer, and many mobile readers are far less forgiving. They just grab the nearest system font and call it a day. This problem is most common with custom or commercial fonts. If it's not Arial, Times New Roman, or Helvetica—one of the handful of 'PDF-safe' faces bundled with operating systems for decades—it's at risk. Anyone who has used a sharp Google Font, a purchased typeface from MyFonts, or a specific brand font knows this pain. There's a real chance it won't be embedded in your exported PDF. The fix exists, but you have to know where to look in your software—and understand what CocoConvert can and can't do to help.
How to Check Whether Fonts Are Actually Embedded
First, let's confirm that missing embedding is the real culprit. Don't just start changing settings blindly. Open your PDF in the free Adobe Acrobat Reader and navigate to File → Properties → Fonts. This tab lists every font in the document. You're looking for the status next to each font name. If it says 'Embedded' or 'Embedded Subset,' you're golden. If you see a font listed with no embedding status, or worse, the word 'Substituted,' that's your problem. That font isn't actually in the file and will break on any machine that doesn't have it installed. No Acrobat? No problem. You can use a free online tool like PDFCandy. For a truly low-tech approach, you can even open the PDF in a text editor and search for the string `/FontDescriptor`. Each embedded font will have one of these blocks. It's a crude method, but it works in a pinch. The simplest test is often the best: open the PDF on another device. Use one that definitely doesn't have your custom font installed—an Android phone, a colleague's laptop, a fresh virtual machine. If the text looks different there, the font isn't embedded. Finally, look at the file size. A PDF with embedded fonts is always larger than one without. If you exported a 20-page document with four custom fonts and the resulting PDF is a feather-light 180 KB, that's a huge red flag. The fonts didn't make it. A properly embedded version of that same document should be closer to 600 KB or even 1.5 MB, depending on the glyphs included. Font data has weight, and in this case, that weight is a very good sign.
Fixing Embedding at the Source: Word, Google Docs, and InDesign
The best place to fix font embedding is right at the source, inside the application where you created the document. Get it right here, and you won't have to fix it later. **Microsoft Word (Windows):** Navigate to File → Options → Save. Down at the bottom of that dialog, you'll find the magic checkbox: 'Embed fonts in the file.' You'll also see two sub-options. 'Embed only the characters used in the document' is a smart way to reduce file size by only including the glyphs you actually used. 'Do not embed common system fonts' saves more space by skipping fonts like Arial that are already on most computers. I recommend checking both for almost every situation. Once the font is embedded in the .docx, exporting via File → Export → Create PDF/XPS will carry that precious font data through. **Microsoft Word (Mac):** Frustratingly, the Mac version of Word's Save dialog is missing the font embedding checkbox. This is a long-standing limitation. Your best workaround is to use the system print dialog (File → Print → PDF) or to install a dedicated PDF printer driver like PDF995. The other, more clunky option, is to open the file in Word for Windows, embed the fonts there, save the .docx, and then move it back to your Mac for exporting. **Google Docs:** You get zero direct control over font embedding in Google Docs. When you use File → Download → PDF Document, Google's servers do the rendering. They are good at embedding fonts from the Google Fonts library. But if you've used a browser extension like 'Font Changer' to use your own fonts, forget it. Those will not be embedded because Google's export pipeline can't see them. The rule is simple: if you plan to export a Google Doc to PDF, stick to native Google Fonts. **Adobe InDesign:** InDesign is built for this. Go to File → Export → Adobe PDF. In the export dialog, click on the 'Output' panel. Choose a PDF/X standard like PDF/X-1a or PDF/X-4. These are bulletproof for print work. The great thing about InDesign is that it embeds all fonts by default when using these standards. There's no single 'embed fonts' checkbox because the tool assumes you want it done right. It will only fail (and warn you) if a font's license explicitly forbids embedding.
What CocoConvert Does During Conversion
When you upload a file like a .docx or .pptx to CocoConvert for PDF conversion, our service doesn't just change the file extension. It renders the document from scratch on our servers and then generates a fresh PDF. This process means the final quality hinges entirely on which fonts are available on those servers. So, what fonts do we have? We've installed the complete Google Fonts library, all the standard Microsoft Office fonts (Arial, Calibri, Cambria, Times New Roman, and the gang), and a healthy selection of common open-source typefaces. If your document uses any of these, they will be embedded perfectly in the output PDF. Now for the reality check. If your document uses a commercial font you bought and installed locally—think Proxima Nova, Brandon Grotesque, or a custom brand typeface—our servers do not have it. They can't. Legally, no cloud conversion service can install every commercial font in existence; it would be a massive violation of font licenses. Our server will be forced to substitute a fallback font, and your PDF will look wrong. There are two solid workarounds for this. The best option is to embed the font in the source file before you upload it (like using Word's embed feature we just covered). The other option is to convert your text to outlines in a program like Illustrator or Affinity Publisher before converting. This turns the text into vector shapes, locking in the appearance forever. The big tradeoff is that the text is no longer text; it's just shapes. It becomes unsearchable and can't be copy-pasted, which can be a dealbreaker for accessibility and usability. For most standard business documents that stick to system or Google fonts, CocoConvert will handle the embedding for you, no extra steps required.
The Subset vs. Full Embed Question
When a PDF embeds fonts, it can either embed the entire font file or just a 'subset' of the characters that actually appear in the document. Let me be clear: subsetting is the right choice 99% of the time, and it's what CocoConvert does by default. The file size difference is dramatic. For example, a complete copy of a typeface like Noto Sans, with its support for dozens of scripts, can be 500 KB or more per weight. If your document only uses the English alphabet and some punctuation, you're using maybe 200 of the font's 2,000+ available glyphs. Subsetting intelligently embeds only those 200 glyphs, adding just 40–60 KB to your PDF instead of a hefty 500 KB. So when would you ever want to embed the full font? The only common scenario is if the PDF needs to be edited later, like if a print shop has to make last-minute text corrections. With a subsetted font, an editor can't add text using characters that weren't in the original document, because those glyphs simply aren't in the file. If you're sending a file to a commercial printer, you must ask them what they prefer. Most modern print workflows are fine with subsetting, but don't assume—confirm it. If you're stuck with a broken PDF from someone else, you can fix it. Acrobat Pro's Preflight tool (Tools → Print Production → Preflight → PDF Fixups → 'Embed missing fonts') can re-embed fonts. It will scan the PDF and try to embed the necessary fonts from your local system, patching the file. While CocoConvert doesn't offer this specific repair service, for heavy-duty PDF surgery, Acrobat Pro or Enfocus PitStop are the industry-standard tools.
Font Licensing and Embedding Restrictions
Just because you have a font file doesn't mean you can legally embed it in a PDF. Some fonts are technically restricted from embedding, even if you have a license. This is controlled by a flag inside the font file itself, usually called the 'fsType' or 'Embedding' flag. There are four main levels: - **Installable (0):** The most permissive. The font can be embedded, and the recipient can even install it. Most open-source fonts use this. - **Editable (8):** The font can be embedded, and the document can be edited with that font. - **Print and Preview (4):** The font can be embedded for viewing and printing only. The PDF cannot be edited in a way that changes text set in that font. - **No Embedding (2):** The font cannot legally be embedded at all. Period. You can check a font's embedding permissions yourself with a free tool like 'Font File Analyzer' or by inspecting its metadata in Typeface (on macOS) or Font Book. If a font has the 'No Embedding' flag, professional tools like Acrobat and InDesign will simply refuse to embed it and will pop up a warning. This is most common with older commercial fonts from the 90s and early 2000s; thankfully, most modern fonts are more permissive. If you run into this wall, you have a few options. You can contact the font vendor and see if they sell an embedding-licensed version. You can convert the text to outlines, as we discussed earlier. Or, you can switch to a similar open-source font. Google Fonts and Font Squirrel are treasure troves of fonts with licenses that explicitly allow PDF embedding. When brand consistency is non-negotiable, a good designer can usually find a Google Font that's a close-enough match to a restricted commercial one for day-to-day business documents.
A Practical Checklist Before You Export
A quick pre-flight check before you export can save you from an embarrassing and confusing back-and-forth, especially if the PDF is headed to a client, a printer, or a regulatory body that has no time for garbled fonts. **1. Audit your fonts.** Know exactly what you're using. In Word, use the Find & Replace dialog's 'More' options to search by font. InDesign makes it easy with Type → Find Font. In Google Docs, you're on your own—there's no built-in tool, so you have to scan manually or find a script. **2. Know their origin.** Where did each font come from? Is it a standard system font? A Google Font? Or a purchased commercial font? That last category is the one that requires your full attention. **3. Embed at the source.** Use the settings we covered earlier to enable font embedding in your creation tool *before* you export. **4. Prep for CocoConvert.** If you're uploading to our service, double-check that every font is either a system font, a Google Font, or already embedded in your source file. If you're using commercial fonts that aren't embedded, your two choices are to embed them in Word first, or convert that text to outlines in a vector app like Illustrator. **5. Verify the output.** Don't just assume it worked. After exporting, open the PDF in Acrobat Reader, go to the Font Properties, and confirm every single font shows 'Embedded' or 'Embedded Subset.' **6. Do the 'other device' test.** This is the moment of truth. Open the PDF on your phone or a machine where your custom fonts are definitely not installed. What you see there is what your recipient will see. Font embedding problems are entirely solvable, but only if you catch them before the file is out in the wild. Once a PDF is distributed without the right fonts, you can't fix it on everyone's machine. You have to fix the source and send it all over again. Make this verification a habit, and you'll never have to apologize for a broken PDF again.