Converting Word → PDF sounds simple… until you actually try to do it without a server.
Most tools solve this by uploading your .docx, converting it somewhere in the cloud, then sending it back. That works — but it completely breaks privacy and falls apart for larger documents.
I wanted something different:
• No uploads
• No servers
• No waiting
• No trust required
That’s how the Word to PDF tool in ihatepdf came to life.
⸻
The First Reality Check
Browsers don’t understand Word files.
There’s no native API that says:
“Hey browser, please convert this .docx into a PDF.”
So the real challenge wasn’t conversion.
It was recreating Word’s layout faithfully inside the browser.
If the layout is wrong, the PDF is useless.
⸻
Step 1: Rendering Word Files Locally
The foundation of the entire flow is previewing the Word document correctly.
For that, I used docx-preview.
Why preview first?
Because Word → PDF isn’t really “conversion”.
It’s actually:
Word → HTML → Canvas → PDF
If the HTML preview is wrong, the PDF will be wrong too.
So the app:
1. Reads the .doc / .docx as an ArrayBuffer
2. Renders it into the DOM using docx-preview
3. Verifies headers, footers, tables, images, lists, and spacing
4. Only then allows conversion
If preview fails, conversion is blocked — no broken PDFs.
⸻
Step 2: Waiting for Reality (Fonts & Images)
This sounds boring, but it’s critical.
Word documents depend heavily on:
• custom fonts
• embedded images
• layout-sensitive spacing
So before converting anything:
• all images are fully loaded
• document.fonts.ready is awaited
• extra delays ensure layout stabilization
This prevents:
• missing images
• font fallbacks
• shifted text in the final PDF
Small wait. Huge reliability gain.
⸻
Step 3: Cloning the Document (Without Breaking It)
Here’s where things get tricky.
You cannot directly convert the preview DOM.
It’s interactive, styled for screen, and often includes editor wrappers.
So instead:
• the document is deep-cloned
• rendered into an off-screen container
• sized exactly to A4 dimensions
• stripped of UI-only styles
This container lives far outside the viewport, invisible to the user.
⸻
Step 4: Preserving Word’s Styling (The Hard Part)
Word documents are brutal with styles:
• nested tables
• mixed fonts
• weird margins
• inconsistent spacing
• links, lists, headings, paragraphs
So instead of guessing styles, the converter reads computed styles from the browser and reapplies them explicitly.
That includes:
• font family, size, weight
• line height
• margins & padding
• text alignment
• list indentation
• table widths and borders
• image sizing
This is done recursively — element by element.
It’s slow to write, but it’s the only way to keep fidelity.
⸻
Step 5: High-Resolution Rendering
Once the layout is locked, the document is rendered using html2canvas.
Key choices here:
• scale: 3 for print-quality output
• white background (no transparency bugs)
• CORS-safe image handling
• no viewport scrolling hacks
The result is a single high-resolution canvas representing the full document.
⸻
Step 6: Turning Canvas Into a Real PDF
Now comes jsPDF.
The canvas is sliced into A4-sized pages, respecting:
• page height
• margins
• pagination boundaries
Each page is added as a compressed JPEG:
• 98% quality
• fast rendering
• minimal artifacts
This creates a proper multi-page PDF, not a single stretched image.
⸻
Safari & Mobile Compatibility (The Hidden Pain)
Safari — especially iOS Safari — aggressively blocks programmatic downloads.
So the app uses a fallback strategy:
• standard download where possible
• window.open() for iOS
• share sheet support when needed
This ensures the PDF is downloadable everywhere — desktop or mobile.
⸻
Why This Works Without Servers
At no point does the Word file:
• leave the device
• touch a backend
• get uploaded to a third party
Everything happens:
• in memory
• inside the browser sandbox
• under the user’s control
You can literally disconnect from the internet after loading the page and still convert documents.
⸻
What This Approach Trades Off
This isn’t magic.
Trade-offs are real:
• extremely complex Word features may still differ slightly
• very large documents take more time
• conversion is CPU-heavy (by design)
But the benefits outweigh it:
• zero privacy risk
• instant feedback
• no file limits hidden behind paywalls
⸻
Why I’m Happy With This Solution
This approach isn’t the easiest way to build Word → PDF.
It’s just the most honest one.
No dark patterns.
No uploads disguised as “free”.
No silent data handling.
⸻
Try It Yourself
You can test the Word to PDF tool here:
👉 https://ihatepdf.cv
Upload a .docx, scroll the preview, convert — and watch your Network tab.
Nothing leaves your machine.
⸻
Final Thought
Browsers are no longer “just for websites”.
With careful engineering, they can handle:
• document rendering
• layout preservation
• print-quality PDFs
• all without servers
The trick is respecting:
• the browser’s limits
• the user’s privacy
• the document’s structure
That’s what this tool is built around.
Top comments (0)