Why your converted document changed fonts

A document file does not contain its fonts

A .docx does not usually carry the fonts it uses. It carries their names. When you open it, your computer looks up "Calibri" in its own font library and renders with what it finds. That works on your machine because the font is installed there.

A conversion server is a different machine. It has a font library too, but it is not yours — it has a curated set of open fonts, not whatever came with your copy of Office or whatever you installed for a client project last year. When the document asks for a font that is not there, the renderer has to choose a replacement.

PDF works differently, which is why converting to PDF is the reliable direction: a properly generated PDF embeds the fonts it needs inside the file. That is the whole point of the format. It is also why a PDF made on the server uses the server's substituted font, permanently, rather than the one you saw in Word.

What substitution actually changes

Substitution is not just a visual swap. Every font has its own metrics — the width of each character, the height of the lines, the spacing between letters. A replacement font with wider characters pushes more words onto the next line, which pushes paragraphs down, which moves page breaks.

So the visible symptoms of a font substitution are usually not "the letters look different". They are: a table that no longer fits its column, a heading that has fallen to the bottom of a page on its own, a one-page CV that is now one page and three lines, or a slide where the text overflows its box.

• Page count changes — the most common report, and almost always metrics rather than a bug.
• Tables widen and wrap differently, sometimes breaking across pages where they did not before.
• Text overflows fixed-size boxes in presentations, because a slide box does not reflow.
• Justified text develops uneven word spacing, because the justification was tuned for different character widths.

What our converter does about it

Before rendering, the converter inspects the source file and pulls out the list of fonts it references. Each one is checked against the fonts actually available. Where a font is missing, an explicit substitution is written into the renderer's configuration, so the replacement is a deliberate close match rather than whatever the renderer would have fallen back to on its own.

There is extra handling for scripts where a bad substitution is more than cosmetic. CJK text falls back to a font that actually contains Chinese, Japanese, and Korean glyphs, rather than one that would render them as empty boxes. And a specific Arabic font that is common in documents but renders poorly in the headless environment is swapped for one the renderer handles correctly.

Arabic documents get one more pass. Right-to-left paragraphs with certain justification settings come out stretched or misaligned when rendered headlessly, so justification is normalized before the conversion runs. This is not a general-purpose fix anyone needs to know about — it is a specific repair for a specific real failure, and it is why Arabic documents convert cleanly here.

How to avoid the problem entirely

• Use common fonts in documents you plan to convert. Arial, Times New Roman, Calibri, and the standard open equivalents substitute predictably or are present outright.
• If the exact typeface matters — a brand document, a designed template — export the PDF yourself from the application that has the font installed, and convert from that PDF rather than from the source document.
• In Word, turn on "Embed fonts in the file" before saving the .docx. Not every converter reads embedded fonts, but it costs nothing and helps in the cases where it is read.
• Check page count first. It is the fastest signal that a substitution happened: if the converted document has the same number of pages as the original, the metrics almost certainly matched.
• For anything going to print or to a client, open the output before you send it. This applies to every conversion, but font substitution is the specific failure that looks fine in a thumbnail and wrong at full size.

The direction that is always safe

Converting from a PDF does not have this problem, because the PDF already carries its fonts. If you have a choice of source and the typography matters, start from the PDF.

The corollary is worth stating plainly: if a document's exact appearance is important, the PDF is the authoritative artifact, and the editable source is the thing that will render differently on every machine that opens it. That is not a flaw in the conversion — it is the difference between a document and a rendering of one.