Print quality + safe sharing
PDF preflight checklist: 12 checks before printing or sharing
Preflight the exact PDF you will deliver, compare it with written requirements, and record every warning you accept. A page that looks correct can still contain wrong page boxes, low-resolution placed images, missing fonts, private metadata, attachments, scripts, or recoverable text beneath a black rectangle.
For print, start with page geometry, effective image PPI, fonts, color/output requirements, and a rendered proof. Before external sharing, add metadata, attachments, actions, redaction verification, accessibility, and recipient review. The local checkers below collect evidence; your printer, court, publisher, client, or policy defines pass and fail.
Print-production track
Run checks 1–6, then apply the printer’s own PDF/X, color-profile, bleed, transparency, ink, and finishing requirements. Never substitute a generic “300 DPI” badge for the written job specification.
External-sharing track
Run checks 1 and 6–12. Add checks 2–5 when image fidelity or faithful reproduction matters. For sensitive or regulated material, require independent human review of the exact output.
The 12-step PDF preflight checklist
| # | Check | Evidence to collect | Local resource |
|---|---|---|---|
| 1 | Final-file identity | Filename, byte size, SHA-256, page count, reviewer, date, and the requirements used | Record these before editing anything else |
| 2 | Page size and rotation | Dimensions for every page, mixed sizes, and effective orientation | Page size and box checker |
| 3 | Trim and bleed geometry | MediaBox, CropBox, TrimBox, BleedBox, and the difference between them | Page box report |
| 4 | Effective image resolution | Pixel dimensions divided by each image’s actual placed size; flag repeated low-PPI placements | Effective image PPI checker |
| 5 | Font embedding and text mapping | Embedded, subset, and unembedded fonts; Type 3 use; ToUnicode coverage; extraction warnings | Font and ToUnicode checker |
| 6 | Rendered output | Visual proof in a second viewer, edge content, transparency, overprint-dependent areas, thin rules, and expected page order | Render pages to PNG |
| 7 | Metadata and identifiers | Info dictionary, XMP, author, title, software, dates, custom fields, and unexpected strings | Privacy and active-content inspector |
| 8 | Attachments, forms, links, and actions | Embedded files, form fields, annotations, external links, JavaScript, launch actions, and open actions | Structured-object report |
| 9 | Redaction verification | Known-phrase results, all extracted text, likely covered text, and pending Redact annotations | PDF redaction checker |
| 10 | Accessibility and reading order | Tagged structure, language, title, headings, alternate text, table semantics, keyboard order, and screen-reader output | Use an approved accessibility checker and manual assistive-technology review |
| 11 | Recipient workflow | Password delivery method, naming convention, file-size limit, permitted PDF version, signature expectations, and upload acceptance | Test the actual delivery channel with a non-sensitive file when possible |
| 12 | Final independent review | Second-person or approved-system signoff on the exact checksum and every unresolved warning | Keep the report with the final deliverable |
The versioned JSON records every check, track, evidence field, local tool, interpretation limit, and source.
1. Freeze the exact file before you inspect it
Preflight evidence is only useful when it identifies the file it describes. Renaming is harmless; resaving, optimizing, printing to PDF, applying a password, combining pages, signing, or sanitizing can change the byte sequence and sometimes the document’s structure. Record the SHA-256 of the final candidate, then repeat affected checks after any change.
Do not preflight the InDesign, Word, or image source and assume the exported PDF inherited every property. Inspect the exported PDF. Likewise, do not inspect a draft and then send a later download with the same filename.
2. Page boxes are not interchangeable
A PDF can define several rectangles for one page. The MediaBox describes the full physical page boundary; CropBox limits the default visible or printable region; TrimBox identifies the intended finished size; BleedBox describes content intended to extend beyond the trim. A missing TrimBox or BleedBox is not automatically wrong, and a present box is not proof that artwork actually reaches it.
Use the page size and page box checker to inventory the boxes and rotations on every page. Then compare those measurements with the printer’s specification. Adobe’s current InDesign guidance likewise tells users to confirm the intended page range and the document’s bleed settings during PDF export.
3. Measure effective PPI, not an image’s label
Effective pixels per inch is the raster image’s pixel count divided by its placed size in inches. A 1200-pixel image placed four inches wide has about 300 effective PPI; the same image placed eight inches wide has about 150. A metadata label such as “300 DPI” does not override placement geometry.
The PDF image resolution checker reports the actual placed PPI for each raster occurrence. Treat thresholds as requirements, not universal laws. Adobe lists low-resolution images below 300 PPI as a critical issue in a common print-ready workflow, but large-format work, line art, screened output, upsampling, and a printer’s RIP can require different decisions. Ask the printer which content types and thresholds apply.
4. Embedded fonts and selectable text answer different questions
An embedded font program helps the PDF render without relying on a matching font installed on the recipient’s system. A subset contains only glyphs used in the document. ToUnicode maps glyph codes to characters used by extraction, search, copy-and-paste, and many accessibility workflows. A PDF can render acceptably yet have poor or missing Unicode mapping.
Use the font embedding and ToUnicode checker to separate those signals. An unembedded font is a print portability risk; missing ToUnicode is a text-health warning, not proof that the page will render incorrectly. Outlined text removes font dependency but also changes editability, extraction, search, file size, and often accessibility.
5. Visual proof is necessary but not sufficient
Render every page and inspect the result at useful zoom levels. Check page order, blank pages, clipping, crop marks, thin lines, transparency-dependent artwork, black text, image detail, and anything close to the trim. When print consequences matter, use a viewer and output-preview workflow approved by the printer; browser rendering is a useful independent view, not a replacement for a color-managed contract proof.
A visual pass cannot find every structural problem. That is why Adobe’s Preflight tool separately checks colors, fonts, transparency, image resolution, ink coverage, compatibility, syntax, and structure.
6. Safe sharing requires checks outside the visible page
PDFs can carry an Info dictionary, XMP metadata, comments, attachments, form values, links, JavaScript, launch actions, open actions, and other objects that are not obvious in a normal page view. The privacy and active-content inspector inventories many of these structures locally and exports the evidence. A finding is not automatically malicious; it is something to reconcile with the intended deliverable.
Applied redaction needs a separate test. Drawing a black box or cropping a page changes appearance, not necessarily the underlying content. Search known sensitive phrases, extract all text, inspect pending Redact annotations, and review likely text beneath dark covers with the redaction checker. Adobe’s current workflow explicitly distinguishes marking content, applying the redaction, and optionally sanitizing hidden information.
7. A clean automated report is not a certificate
PDF is a complex object format, parsers disagree, and requirements vary. Image-only text may need OCR; unusual encodings can evade extraction; incremental revisions and malformed objects can require forensic tools; accessibility needs manual assistive-technology testing; print color and overprint depend on a managed output condition.
Pass
Every applicable requirement has evidence, the evidence matches the written specification, and the exact final checksum received independent approval.
Pass with accepted warning
A named reviewer accepts a specific mismatch for a documented reason—for example, a deliberately low-PPI background intended for distant viewing.
Do not send
Evidence is missing, a known value survives redaction, an attachment or action is unexplained, the job specification is unknown, or the final file changed after review.
Primary sources and interpretation limits
- Adobe: Analyzing documents with the Preflight tool — identifies common inspection domains including fonts, transparency, resolution, ink coverage, compatibility, syntax, and structure.
- Adobe: Produce print-ready PDF files in InDesign — current export workflow covering page range, presets, bleed, and output conversion.
- Adobe: Redact sensitive content in Acrobat Pro — distinguishes selection, application, and sanitization of hidden information.
- Bland, Iyer, and Levchenko: “Story Beyond the Eye” — peer-reviewed evidence that even some excising text-redaction workflows can leak information through glyph positioning.
- GoPDFConverter methodology — explains local processing claims, independent validators, fixture limits, and release gates for the linked browser checkers.
These sources support the inspection categories and the limits stated here. They do not create one universal acceptance profile. The recipient’s documented requirements control the job.
Frequently asked questions
What does preflight mean for a PDF?
It is a requirements-based inspection of the final file before use. Print preflight checks geometry, fonts, images, color, transparency, and output conditions. Sharing preflight adds metadata, attachments, active content, redactions, accessibility, and recipient workflow.
Is 300 PPI always required?
No. It is a common target for continuous-tone images in many commercial print workflows, not a universal law. Effective PPI, viewing distance, content type, screening, output process, and the printer’s written specification all matter.
Does a PDF that looks right pass preflight?
Not necessarily. The visible page can look correct while fonts are unembedded, images are low resolution at placed size, boxes are wrong, metadata is private, attachments or scripts remain, redaction is cosmetic, or the reading order is inaccessible.
Can these local tools certify my PDF?
No. They collect specific evidence and publish their limits. Consequential print, legal, accessibility, security, or regulatory work needs the approved profile, software, proofing process, and qualified review required by that workflow.