Why Word to PDF May Look Different From Word or WPS

Browser rendering versus Office layout engines

Microsoft Word and WPS Office each ship their own dedicated, decades-refined layout engine purpose-built to lay out .docx documents exactly the way that specific application interprets the format's full feature set - fonts, spacing rules, pagination logic, all of it. This tool has no access to either engine, or to any equivalent: a webpage running in a browser cannot call into Word's or WPS's layout logic, and no browser exposes a way for a script to hand a document to the browser's own native print-to-PDF engine either - that capability is reserved for browser automation tools, not ordinary page scripts.

Given that constraint, this tool takes the only path actually available to browser-based JavaScript: convert the .docx to HTML using a conversion library, render that HTML the way any webpage renders, take a high-resolution screenshot of the result, and slice that screenshot into PDF pages. Every difference described below follows directly from that being fundamentally a different rendering pipeline, not a bug in this specific implementation of it.

Font substitution

This tool always renders with a fixed Arial/Helvetica sans-serif font stack - the specific font, size, and typeface choices set in your original .docx are not read or applied, regardless of what they were originally set to. This is not a font-matching failure so much as a step that does not happen at all: the .docx-to-HTML conversion this tool relies on does not carry font-family information through to the rendering step in the first place, so there is no font name left to try to match by the time rendering happens.

Chinese text still renders correctly and legibly despite the fixed Arial/Helvetica declaration, because the browser doing the rendering automatically falls back to whatever Chinese-capable font is installed on the device running the conversion whenever the requested font has no matching glyph - ordinary browser behavior, not something this tool configures specifically. The specific Chinese font your original document requested is, like every other font choice, not read or applied either way.

Rasterized, non-searchable output, always portrait A4

The output PDF is a picture of your document, not a document with real text inside it - you cannot select, copy, or search its text, because the "screenshot and slice into pages" pipeline produces images, not a text layer. This is the single biggest visual-fidelity difference from Word or WPS's own "Save as PDF" or "Print to PDF," both of which produce a real, searchable text-layer PDF as their normal output.

Every output page is portrait A4, regardless of what page size or orientation your source document specifies - the rendering container this tool uses is a fixed-width portrait layout, so a document set to Letter size, or to any landscape orientation, still comes out as portrait A4 pages. A section explicitly set to landscape in Word does not switch the corresponding output pages to landscape; they render as portrait, just like the rest of the document.

Headers, footers, and page numbers are dropped entirely

Headers and footers - including any page numbers placed inside them - are not carried into the output at all, and do not appear anywhere in the result, not even as ordinary body text the way some other conversion mismatches merely misplace content. This is a direct consequence of which parts of a .docx the underlying HTML conversion step reads: header and footer content lives in separate document parts that this pipeline does not process, so there is nothing for the rendering step to draw even if it wanted to.

If a header, footer, or page number is important for how the PDF will be used - a running title, a confidentiality notice, page references in a printed packet - it needs to be added to the finished PDF afterward with a dedicated tool (this site's own Add Header/Footer or Add Page Numbers, for example), rather than expected to survive from the source document.

Tables, lists, images, and hyperlinks

Tables fare noticeably better than in the reverse direction (PDF to Word): because this pipeline goes through HTML, tables are rebuilt as real HTML tables before rendering, so their row-and-column grid comes through correctly - a genuine structural rebuild, not a positional guess. The borders visible in the output are added by this tool for readability, not read from your original table's own border formatting. Bulleted and numbered lists, including multiple nesting levels, are preserved the same structural way and render correctly, including proper indentation per level.

Images embedded in the document are carried through and remain visible in the output. Hyperlinks keep their visible link text and are shown in blue with an underline so they still read as links, but because the whole page is a flat rendered image, no link in the output PDF is actually clickable - a reader needs the destination some other way, such as visible URL text in the document itself.

Frequently Asked Questions