"Print to PDF" and "Export as PDF" produce different files. Here is what changes

Almost every application offers two ways to make a PDF. One is in the File menu: Export, Save As, Download as PDF. The other is in the print dialog: a virtual printer called "Microsoft Print to PDF", "Save as PDF" on macOS, or "Print to file" on Linux. Both produce a file with a .pdf extension and identical-looking pages. They are not the same file, and the difference determines whether the document can be searched, whether its links work, how large it is and how it behaves in every tool that touches it afterwards.

The mechanism: two different paths to the page

When an application exports to PDF, it writes the PDF itself. It knows what its document is made of — paragraphs, headings, a table, an image, a hyperlink — and it can write each of those as the corresponding PDF construct: text with an embedded font, a link annotation, a bookmark for each heading, a tagged structure tree if the application supports accessibility. Word, LibreOffice, Google Docs, InDesign and browsers via "Save as PDF" in Chrome all do this.

When an application prints to PDF, it does not write a PDF. It draws the page onto the operating system's printing subsystem, exactly as it would for a physical printer, and a driver at the other end converts the stream of drawing commands into a PDF. The driver has no idea what the document was: it receives lines, filled shapes, glyphs at positions and images. It does not know that a heading was a heading, that blue underlined text was a link, or that the page belonged to chapter three. Whatever the application did not draw, the driver never sees.

What you lose with the print path

• Links. A hyperlink is not drawn; only its blue underlined text is. The printed PDF has the text and no link. This is the single most common complaint about printed PDFs.
• Bookmarks and the outline. Exported PDFs from Word or a browser can carry a navigable table of contents in the viewer's sidebar. Printed PDFs never do.
• Structure and accessibility. Tags marking headings, lists, tables and reading order — required for screen readers and for PDF/A-1a — are not part of the drawing stream. A printed PDF is inaccessible by construction.
• Metadata. Title and Author come from the driver, not the document; you often get "Microsoft Word — filename.docx" as the title and the Windows user as the author.
• Sometimes text itself. Some drivers, and some applications when printing, convert text to outlines (vector shapes) or, worse, rasterise the page to an image. The result looks identical and has no selectable or searchable text. Print-to-PDF from a browser or from Word usually keeps text; from design software and some PDF viewers it often does not.
• Fidelity of page size. The driver uses its own paper setting. A Letter document printed to an A4 driver is scaled or reflowed; an export honours the document's own page size.

What you sometimes gain

There are reasons the print path exists and still gets used. It flattens. A PDF with form fields, comments, layers, embedded JavaScript or transparency groups, printed to PDF, becomes a plain document with none of those — which is exactly what you want when sending a filled form to someone who should not be able to edit the fields, or when a downstream tool chokes on the interactive parts. It also normalises: whatever exotic construct the source used, the output is what a printer would have made of it, and that tends to open everywhere.

And it is universal. Applications with no PDF export at all — old software, some web apps, internal tools — can still print, so print-to-PDF is the only way to get a PDF out of them.

How to tell which one you have

1. Open the file and try to select a word with the cursor. If nothing selects, the text is outlines or an image. Our PDF-to-text tool gives the same answer faster: if it returns nothing for a page that clearly shows text, that page has no text objects.
2. Look at the viewer's sidebar for bookmarks. Present: exported. Absent: either printed, or exported from an application that does not write them.
3. Hover over something that should be a link. If the cursor does not change, the link was not written.
4. Check the document properties. Producer reading "Microsoft: Print To PDF", "macOS Quartz PDFContext" (which is what Apple's Save as PDF from the print dialog uses) or a printer-driver name means the print path. "Microsoft Word", "LibreOffice", "Skia/PDF" (Chrome) or "Acrobat PDFMaker" means export.
5. Compare sizes. For the same document, the export is usually smaller for text-heavy pages (fonts are embedded once, subsetted) and the print version is larger, sometimes dramatically so when pages were rasterised.

What this means for the tools you use afterwards

Tools that work on the structure of a PDF — merging, splitting, rotating, page numbering, watermarking — do not care which path made it; they operate on pages. Tools that work on content do. Text extraction and OCR need text objects or, failing that, an image to recognise. Compression behaves very differently: an exported PDF with embedded fonts and vector graphics may barely shrink, while a printed PDF whose pages were rasterised can shrink by a large factor because it is essentially a folder of images. Conversion to Word or Excel needs text with positions and works poorly on outlined or rasterised text. If a converted document comes out empty or garbled, the first thing to check is whether the source PDF ever had text in it.

The recommendation

Export when you can. It is the richer file: searchable, linkable, accessible, smaller, and it preserves the page size you set. Use the print path deliberately, for what it is good at: flattening an interactive document, normalising something odd, or getting a PDF out of software that cannot make one. And if someone sends you a "PDF that cannot be searched", you now know what happened to it and that no tool can restore the text — only OCR can re-create it.