Convert DOCX to PDF on Mac (and Keep the Layout)

Same 4,719-byte two-page test document through every route available on a stock Mac plus one install.

The last two rows produced the same file. That is not a coincidence and it is worth being direct about: Smol’s Office conversion is LibreOffice-backed. Both PDFs were 29,350 bytes, two pages, with Producer: LibreOffice 26.2.3.2 (AARCH64) and Creator: Writer in the metadata and identical embedded font subsets. A byte comparison found the first difference at byte 19,887 — the creation timestamp.

Yes, twice over, and neither route is the one the Terminal tutorials suggest.

Pages. It opens DOCX directly. Then File → Export To → PDF, pick an image quality, save. For a single document this is the correct answer and it costs nothing. Pages will warn you about anything it changed on import, which is more than most converters do.

The print dialog. ⌘P in any app that can print, then the PDF dropdown at the bottom left and Save as PDF. It uses Quartz, it is universal, and it renders exactly what the app on screen renders — which makes it the most faithful route available when the app already displays the document correctly.

Not textutil. This is the recommendation that gets copied around and it does not work:

$ textutil -convert pdf contract.docx
Invalid output format.

Exit code 1. textutil writes txt, rtf, rtfd, html, doc, docx, odt, wordml and webarchive. PDF is not on the list and never has been. What it can do is feed a plain-text PDF route that is entirely built in:

textutil -convert txt -output plain.txt contract.docx
cupsfilter plain.txt > contract.pdf

That produced a valid 25,511-byte one-page PDF stamped Producer: macOS Version 27.0 (Build 26A428) Quartz PDFContext. It also threw away every heading, every font and the whole layout, and collapsed two pages into one. Useful for archiving text, useless for sending a contract. Note also that cupsfilter will not take HTML on macOS 27 — it answers No filter to convert from text/html to application/pdf — so the intermediate-HTML variant of this trick is dead.

Because line breaks are decided at render time from the metrics of the font that is actually available, and the font named in your DOCX usually is not. Microsoft’s defaults — Calibri, and since 2024 Aptos — do not ship with macOS. Every converter therefore substitutes, and they do not substitute alike.

We made four copies of the same document, changed only the body font named inside it, and read back which typeface each PDF actually embedded:

Read the first two rows carefully, because they are good news. Carlito and Caladea are metric-compatible clones of Calibri and Cambria: every glyph occupies the same advance width as the original, so lines break in the same places and page counts hold. LibreOffice bundles them precisely so Word documents survive. The typeface is not Calibri, but the layout is Calibri’s layout.

The third row is the failure. Aptos has no metric-compatible clone, so LibreOffice fell all the way back to Liberation Serif — a serif face standing in for a sans-serif one. Your headings stay sans, your body text turns into something Times-shaped, and every line break moves. If you have a document written in the current Word default and the PDF came out looking oddly old-fashioned, that is what happened.

In rough order of how well they work.

• Export the PDF from the machine that wrote the document. If it was written in Word on Windows with Aptos installed, the PDF made there is correct by definition. A conversion on another machine is always a re-render.
• Install the font. Calibri and Cambria come with Microsoft Office for Mac; Aptos comes with Microsoft 365. Once present, they are embedded as themselves — our Helvetica control proves the mechanism, coming back as CAAAAA+Helvetica rather than a stand-in.
• Embed the fonts in the DOCX before you send it. Word’s Save → Embed fonts in the file option carries the outlines inside the document, so the converter has nothing to guess. Most licences permit embedding for viewing.
• Design in fonts that exist everywhere. Helvetica, Times New Roman, Arial, Georgia and Verdana are on every Mac and every Windows machine. A contract template in Georgia will never surprise you.
• Or send the DOCX and stop converting. If the recipient is going to edit it, a PDF is the wrong deliverable anyway.

One thing that does not help: converting twice, or via ODT, or through a web service. Every one of those is another render with another substitution table.

Here the free route wins on raw speed, and it wins by a lot. Twelve copies of the test document, three ways:

The gap between the first two rows is the lesson most shell scripts get wrong. LibreOffice pays its startup cost once per invocation, so for f in *.docx; do soffice …; done is 6.4× slower than handing it the whole glob:

soffice --headless --convert-to pdf --outdir ./out *.docx

Smol was the slowest of the three at 40.43 seconds for twelve files. It buys you a Finder Quick Action, a watched folder, and a single drop target that also takes spreadsheets, presentations, images and video without you choosing a filter — not throughput. If throughput is the whole problem, use the command above.

For a repeatable pipeline there is a third option worth knowing: Smol ships an MCP server, so Claude Code, Codex and Google Antigravity can drive the conversion directly as a tool call. That matters when the conversion is one step inside a larger job an agent is already running — gather the documents, convert, compress the results, file them — rather than something you are running by hand.

For DOCX to PDF specifically, most of the time. Pages is already installed, it is free, and for one document it is the shortest path there is. LibreOffice is free, and since it is the same engine producing the same bytes, paying for a wrapper around it only makes sense if you want the wrapper.

Where the wrapper earns its keep:

• You do not want LibreOffice on the machine. A 700 MB office suite to convert documents is a real cost, and Smol bundles what it needs.
• Mixed folders. DOCX, XLSX, PPTX, images and video in one drop, one output setting. Document output covers pdf docx odt rtf txt html; the full format reference is here. Note there is no .pages output.
• Right-click in Finder. A Quick Action for people who will never open a Terminal.

Smol is $29 once, which is the comparison that matters against Acrobat’s annual fee rather than against LibreOffice’s zero. If the PDF then turns out to be too big for the portal you are uploading it to, that is a separate job.

Going the other way — spreadsheets rather than documents — has its own traps: XLSX to CSV loses more than you expect.

MacBook Pro (Mac14,9), Apple M2 Pro, 10 cores, 16 GB, macOS 26A428. LibreOffice 26.2.3.2 (AARCH64), Smol 1.0.34. Fonts read back with pdffonts, metadata with pdfinfo and exiftool, substitution predictions with fc-match. Timings from /usr/bin/time -p, wall-clock real; Smol’s figures are its own reported job durations.

The test document was built for this article, not taken from anywhere: an HTML file was run through textutil -convert docx and then its word/document.xml was edited so the body runs name Calibri and the heading runs name Cambria. Worth recording because it is a fidelity finding in itself — textutil flattened every font-family in the source HTML to “Times” and dropped the HTML table entirely. Pages and the print dialog were described but not timed, because neither can be driven headlessly. Every fixture was deleted afterwards.