What this tool does
NexKit PDF Tools converts a Word .docx document into a PDF by rendering it to an image in your browser and saving that as a PDF page, or several pages for longer documents. This works entirely in your browser: no server ever sees your document.
Because browsers do not expose a way for a webpage to hand a document to their own native print-to-PDF engine, this tool renders your document's visible content instead of producing a text-layer PDF. The result looks like your document, but its text is not selectable or searchable, similar to a photo or scan of a printed page.
How to convert Word to PDF
Open the Word to PDF page and choose a .docx file. The tool works through three visible stages - reading the document, rendering it, and building the PDF - with a real percentage progress bar, and you can cancel at any point before the PDF finishes; your selected file stays in place afterward so you can try again.
Download the PDF and review it before sharing, especially formatting such as underlines, page breaks, and anything discussed below, none of which is preserved exactly in this MVP.
What Word to PDF can and cannot preserve
This tool renders your document's visible content, so headings, bold and italic text, ordered and bulleted lists (including nested levels), paragraph text, tables, and images all carry over and remain visible in the output PDF, in Chinese, English, or a mix of both.
What it does not preserve: underline formatting is dropped; the source document's own explicit page breaks are ignored, with output pages determined purely by rendered content height instead; and, as covered in more detail below, headers, footers, page numbers, section breaks, and landscape page orientation are not carried over at all. Direct paragraph indentation set without a list is also not preserved by this MVP's conversion step, separately from list-item indentation, which is.
Why this is an image, not a searchable PDF
A webpage has no browser API that lets it hand a document to the browser's own native print-to-PDF engine - that capability is reserved for browser automation tools, not ordinary scripts running on a page. Given that constraint, this tool takes the only approach a browser script actually has available: it converts your .docx to HTML, renders that HTML off-screen exactly as a browser would display it, takes a high-resolution screenshot of the result, and slices that screenshot into PDF pages.
The practical consequence is that 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, and a screen reader cannot read it as text either - it behaves like a scanned page. If you need a searchable, editable result instead, that is a fundamentally different kind of output this tool does not produce.
Fonts and Chinese-text rendering
This tool always renders your document using a fixed Arial/Helvetica sans-serif font stack - the specific font, size, and typeface choices in your original .docx are not read or applied, regardless of what they were set to. This is a deliberate MVP simplification, not a bug: the conversion step that turns your .docx into HTML does not carry font names through to the rendering step at all.
Chinese text - Simplified, Traditional, or mixed with English on the same line - renders correctly and legibly. This works because the browser doing the rendering automatically falls back to whatever Chinese-capable font is installed on your own device whenever the requested Arial/Helvetica font has no matching glyph, which is ordinary browser behavior rather than something this tool configures specifically for Chinese. If a visitor's device has no CJK font installed at all, rendering would fall back to the browser's own default behavior for missing glyphs, though this was not something this MVP could reproduce or verify directly.
Tables, images, and hyperlinks
Tables are rebuilt as real HTML tables before rendering, so their row-and-column grid is preserved correctly - a genuine structural rebuild, not a text-position guess. Borders visible in the output are added by this tool for readability rather than read from your original table's own border settings.
Images embedded in your 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 image, no link in the output PDF is actually clickable - a reader would need to know the destination some other way, such as from your document's own visible URL text.
Page breaks, section breaks, headers, footers, page numbers, and orientation
None of these are preserved by this MVP, and each was verified directly rather than assumed. An explicit page break placed in Word does not force a new PDF page here - pages are determined purely by how tall the rendered content is, so content before and after your page break can end up on the same output page. Word section breaks are not recognized at all: multiple sections are rendered as one continuous flow with no visible divider between them.
Headers and footers - including any page numbers placed inside them - are dropped entirely and do not appear anywhere in the output, not even as ordinary body text. Page orientation is not preserved either: every output page is portrait, regardless of whether a section in your source document was explicitly set to landscape.
Legacy .doc files, encrypted documents, and WPS-generated .docx
Legacy binary .doc files and password-protected .docx files are stored using the same underlying container format, which this browser-based tool cannot open either way - both are rejected with a message naming both possibilities, since there is no way to tell which one caused the rejection from the file alone. Save the file as an unprotected, modern .docx (in Word: File > Save As > Word Document) and try again.
.docx files exported from WPS Office are standard OOXML, the same underlying format Microsoft Word itself produces, and this tool converts them the same way - it reads and renders standard OOXML markup regardless of which application produced it, rather than looking for anything Word-specific.
Troubleshooting
If conversion fails with a message about a damaged file, either the .docx is genuinely corrupted or it is a legacy .doc/encrypted file misnamed with a .docx extension - re-save it as a fresh, unprotected .docx and try again. If it fails as too large, or the converted document exceeds this MVP's page limit, try splitting the source document into smaller files or removing large embedded images before converting.
If a cancellation is in progress, note that the current stage still has to reach its next checkpoint before the tool actually stops - it is not instantaneous mid-render on very large documents. Your selected file remains available afterward either way, so you can retry without reselecting it.
Privacy and file handling
Supported .docx files are processed locally in your browser, including rendering and PDF assembly. Your document and the resulting PDF are not uploaded to NexKit servers for this workflow.
Keep your original .docx file until you have confirmed the converted PDF meets your needs.
Frequently Asked Questions
Are my Word documents uploaded?
No. Supported .docx files are processed locally in your browser, including rendering and PDF assembly. The file is not uploaded to NexKit servers by this tool.
Will the PDF text be selectable or searchable?
No. This tool renders your document to an image and saves it as a PDF, so the output is not selectable or searchable text - it behaves like a scanned page.
Does this preserve underlines and page breaks exactly?
No, not in this MVP. Underline formatting is not rendered, and page breaks are determined by rendered content height rather than the source document's own page breaks. Table borders are added by this tool for readability, not read from the source document.
Will headers, footers, page numbers, and landscape pages be preserved?
No. Headers, footers, and any page numbers inside them are dropped entirely and do not appear anywhere in the output. Word section breaks are not recognized, and every output page is portrait regardless of a source section's landscape setting.
What happens to tables, images, and hyperlinks?
Tables keep their real row-and-column structure since they are rebuilt as HTML before rendering. Images are carried through and stay visible. Hyperlinks keep their visible text and blue underlined styling but are not clickable in the output, since the whole PDF page is a flat image.
Does Chinese text convert correctly?
Yes. Simplified Chinese, Traditional Chinese, and mixed Chinese/English text all render correctly, using whatever Chinese-capable font is installed on your own device as an ordinary browser font fallback - the specific font set in your original document is not read or applied either way.
What about legacy .doc files or password-protected documents?
Neither is supported. Legacy .doc and encrypted .docx files use the same underlying container format, so this browser-based tool cannot open either one; save the file as an unprotected, modern .docx and try again.
What file formats are supported?
Only .docx files (the modern Word format) are supported in this MVP, including .docx files exported from WPS Office, which use the same standard format. Legacy .doc, .odt, and .rtf files are not.
How large a document can I convert?
This MVP supports .docx files up to 15MB that render to up to 30 pages.
Can I cancel a conversion in progress?
Yes. A progress indicator shows the current stage, and cancelling keeps your selected file in place so you can try again. Cancellation takes effect at the next stage checkpoint rather than instantly, since one internal rendering step cannot be interrupted partway through.