forty documents, and Word is not installed

converting one Word document to pdf, without Word

1. open the .docx in TextEdit — double-click usually does it, otherwise right-click → Open With.
2. File → Print, or ⌘P.
3. in the PDF menu at the bottom-left of the dialog, choose Save as PDF.

TextEdit is documented as opening documents from other word processors, Word included: Apple, TextEdit User Guide

Pages will also open a Word file and export it — File → Export To → PDF — and it handles complicated layouts far better than TextEdit. either way, this is per-document, and both will stop and ask you something halfway through a batch.

the same shape shows up elsewhere on a Mac — the built-in answer is real, and it is one file at a time: convert heic to jpg

and if what you actually want is the general tool rather than this one job: the file converter

the Automator recipe to batch convert docx to pdf, and why it fails

the standard answer on the forums is an Automator action wrapping two command-line tools that ship with macOS: textutil to turn the document into html or rtf, and cupsfilter to print that to pdf. it is the first thing you will find, it is free, and it does not work. not «works badly» — cupsfilter exits with an error and writes a zero-byte file.

why cupsfilter refuses the file

run it on macOS 26 and you get «cupsfilter: No filter to convert from text/html to application/pdf»; the rtf variant says the same about text/rtf. this is not a misconfiguration on your Mac. the conversion rules in /usr/share/cups/mime list what can become a pdf, and it is short: plain text, images, and pdf itself. no html rule, no rtf rule.

the filter that used to do it was called nstexttopdf, and it was dropped when OS X El Capitan shipped. that was 2015. the recipe has been repeated every year since by people who have not run it.

the removal, and why copying the filter back does not help: Apple Community, cupsfilter after El Capitan

and the recipe still being given as the answer: Apple Community, batch convert Word to PDF

what textutil actually keeps

textutil itself is better than its reputation, and the half of this that people repeat is the wrong half. converting a .docx with a table, a picture, headers and two named fonts:

• tables survive as tables. a four-by-three table came out with all twelve cells and its borders intact, in both the html and the rtf output.
• fonts survive by name. the html carried «font: 28.0px Futura» and «font: 16.0px Papyrus», and the colour of the heading with them.
• images do not survive. the picture is in the .docx, and the output has no image tag, no image file, and an empty paragraph where it used to be. even rtfd — the one format that can carry pictures — produced a folder with a single text file in it.
• headers and footers do not survive. neither appears anywhere in the output.

so the only variant that runs is the one going through plain text, and that is plain text by definition: three pages of Monaco wrapped at eighty columns, no pictures, the table unstacked into one value per line. a printout of a terminal, not a document.

the same trap sits on the video side, where the free route also costs you knowing what to type: convert mov to mp4

so what actually converts a folder of documents

for one document, stop reading: Print → Save as PDF is thirty seconds and there is nothing to improve on. for a folder, macOS has no built-in answer at all, and the free one that works is LibreOffice run headless from the command line.

the libreoffice route

it keeps the layout because a full office engine does the rendering, and it keeps it properly: the same test document came out with its picture, its table as columns, both named fonts and both headers, in about three seconds. if you already have it, it is the answer.

the cost is the install: roughly 800 mb on disk to turn documents into pdfs, driven from a command line rather than a folder you drop something on.

the invocation and its options: LibreOffice, command-line parameters

how hop converts Word documents to pdf in batches

hop's converter takes documents alongside everything else: .docx, .doc and .rtf come out as pdf or as markdown, and a whole folder is one drop. it is native and offline, with no office suite bundled and nothing large to download.

• markdown goes to pdf too, laid out by hop itself — which is the direction people writing notes usually need.
• the other way round works: the text of a pdf comes out as markdown, and a scanned page is read with Apple's Vision instead of coming back empty.
• Pages, Numbers and Keynote documents are exported in batches by those apps themselves — pdf, or docx, xlsx and pptx — so the layout is done by the app that owns the format rather than by a re-implementation of it.
• originals are untouched; results land beside them as copies.

the Vision part is its own thing, and it is what makes a scanned page come back as text: text recognition

the same engine reads frames rather than pages: copy text from a video

the honest boundary: for a heavily engineered layout, the thing that renders it best will always be the app it was made in. a converter is for the forty files nobody is going to open one at a time.

when the pdf comes out wrong

• the fonts changed. they were not embedded in the source and are not installed on this Mac; the renderer substituted, and everything reflowed from there.
• the page breaks moved. same cause, one step later — different metrics, different line lengths, different pages.
• everything is monospaced and the pictures are gone. that is the textutil-to-plain-text route, and it is the only version of the forum recipe that runs. if the layout matters, it is the wrong tool.
• tables collapsed into one value per line. same cause — plain text has no columns. textutil itself keeps tables; the plain-text step is what flattens them.
• you ran sips on the result and now it is one page. sips rasterises a pdf into a single image, so a three-page document comes back as one page with no selectable text. it refuses .docx outright while still reporting the format, which makes it look broken rather than out of scope.
• tracked changes and comments appear in the pdf. they are part of the file; accept or hide them in the source first, because they are extremely easy to publish by accident.
• the .doc is genuinely old — the pre-2007 binary format. support for it varies by tool, and re-saving it once as .docx solves more problems than anything else you can do.
• it is a form with fillable fields. those are not layout, they are interactive objects, and most conversions flatten them.

and once it is a pdf and too large to send: compress a pdf on Mac

frequently asked questions

can i convert docx to pdf on a Mac without Word?

yes. TextEdit opens .docx and prints to pdf; Pages opens it and exports. neither needs Word, and both work on one document at a time.

how do i batch convert a folder of documents?

macOS has no built-in way. LibreOffice run headless does it properly and is a large install. a converter that takes documents does it in one drop. the Automator recipe with textutil and cupsfilter does not work.

why does cupsfilter say no filter to convert?

because there is none. the rules on macOS only turn plain text, images and pdf into pdf — html and rtf have no route. the filter that did it, nstexttopdf, was removed in OS X El Capitan in 2015.

does textutil keep formatting?

more than it is given credit for. tables come through as tables with their borders, and fonts come through by name. images and headers do not come through at all. the flattening people blame it for comes from the plain-text step after it, not from textutil.

why do the page breaks move after converting?

font substitution. if the original fonts are not embedded and not installed, the renderer picks others with different metrics and every line — and therefore every page — ends somewhere else.

can i use sips to convert documents to pdf?

no. sips reports the format of a .docx and then refuses it with «cannot extract image from file». on a pdf it does run, but it rasterises the whole thing into one page, so it is not a document tool at all.

can i go the other way, pdf to Word?

hop pulls a pdf's text out as markdown, reading scanned pages with Apple's Vision. an exact .docx reconstruction of a designed pdf is a different and much harder problem, and the tools that promise it mostly guess.

the tool behind this

done with convert and compress

other things people do

• a folder of heic, and something that wants jpgfile converter
• mov and mp4 are often the same filefile converter
• QuickTime will not open it. the video is fine.file converter