OnlinePreflight Tool — Catch print problems before your printer does.
C M Y · · K
Print File Check
Spine Width Calculator
Case Board
Front Endpaper
Back Endpaper
Inside Pages
Adjustments
Perfect-bound, thread-sewn & hardcover
Drop artwork here, or click to browse
PDF, JPEG or PNG — multiple files at once. Each page is checked individually and flagged on its thumbnail.
Dieline Studio
Type the measurements. Get the cut and crease lines.
How this works, and its limits
Everything runs in your browser — no server, no upload. Safe for client work under NDA.
Product type: the dropdown above swaps the bleed, safe-margin, image-resolution, and ink-coverage thresholds used below to match what's typical for that product category (e.g. large-format banners are checked against a much lower ppi floor than business cards, since viewing distance is different). It doesn't change how anything is measured — just which numbers count as a pass. Some product types also turn on checks that only make sense for them: business cards get a rounded-corner safety reminder; packaging and labels get a dieline/cut-path spot-color check; cards, flyers, brochures, books, and posters are matched against that product's own standard sizes (e.g. 3.5×2in business card) before falling back to generic sheet sizes; and the binding (saddle-stitch) check only runs for multi-page products. Picking a type re-scans any files already dropped.
PDF: each page's bleed/trim is checked individually and highlighted on its thumbnail with a dashed line showing where the trim edge sits. Every product type requires at least a 3mm bleed beyond the trim edge on a real /BleedBox, or a larger page-margin fallback when there's no /BleedBox and the check is falling back to the page's MediaBox instead (a much weaker signal, hence the higher bar). Safe margin (how far live content must stay from the trim edge) does vary by product — see below. Page-order matching walks the PDF's actual page tree (see below), not raw file order.
Safe margin: a separate check reads the actual position of every text run on the page (via the PDF's text layer, not just structural boxes) and flags any text sitting within the selected product's safe-margin distance of the trim edge as "Not enough margin" — shown on the thumbnail as a fine dotted inset line, red where text intrudes. Text that falls entirely outside the trim box (crop marks, registration marks, printer job info in the bleed/slug area) is ignored, since that's normal and isn't live page content. Tiny attribution/watermark-scale text under ~1.5mm tall (e.g. small stock-photo credit lines, which are conventionally set right at the edge) is also excluded, so only real body copy and headlines trigger this. This only checks text; it doesn't currently check images, logos, or vector shapes placed close to the edge.
Image resolution: each page's content stream is parsed directly — tracking the same coordinate transforms (q/Q/cm) a PDF renderer uses, recursing into Form XObjects — to find each embedded image's actual displayed size on the page, then compares that to its native pixel dimensions for a real effective DPI. Every product type uses the same 250dpi minimum floor (300dpi is the target for a clean pass). This reads only the image's dictionary (width/height) and placement — the actual pixel data is never decoded, so this stays fast even on files with very large embedded photos.
Hairline strokes: the same content-stream walk tracks the w (line width) operator and the current transform's scale factor, flagging any stroke that renders under 0.25pt — thin enough to drop out or print inconsistently on press.
Fonts: each font actually referenced in the file is resolved individually (including composite/CID fonts, via their descendant font's descriptor) to check whether it carries embedded outline data (/FontFile, /FontFile2, or /FontFile3) — reported per font name, not just a file-wide pass/fail.
PDF/X compliance: checks for a declared /GTS_PDFXVersion (e.g. PDF/X-1a, PDF/X-4). Many print vendors require this for submission, though not all do — treat this as informational.
Binding: flags when the page count isn't a multiple of 4, since standard saddle-stitch (folded-and-stapled) imposition requires that. Only shown as relevant for multi-page document-style products (books, magazines, booklets) — irrelevant for single-sheet products like business cards or banners, and skipped for those.
Blank page: samples pixels from the already-rendered thumbnail to flag pages with next to no visible (non-white) content, in case of an accidental blank insert. This is a cheap heuristic on the thumbnail image, not a full-resolution pixel analysis.
Ink coverage (beta, estimate only): combines two rough estimates, neither of which is a real color-managed rasterization the way Adobe Acrobat Preflight does it. (1) The content-stream walk tracks solid rectangle fills and their real CMYK/RGB/Gray fill values, flagging any fill covering 15%+ of the page at an estimated combined ink over the selected product's warn/fail thresholds (packaging and coated stock tend to tolerate higher totals than uncoated/newsprint-style stock). (2) The already-rendered page thumbnail is sampled pixel-by-pixel for large dark/rich areas — this catches photos, gradients, and overlapping shapes the rectangle check can't see, but since browser rendering is RGB-only, it can't tell a plain single-channel black from a heavier CMYK "rich black," so it systematically under-counts real ink in dark areas built with extra process color. Whichever of the two comes back more severe is shown. Neither method sees spot/Separation (Pantone) colors correctly, and a "not checked" or "good" result here is not a guarantee — it's a first-pass flag, not a substitute for your printer's real preflight check.
Page order: per-page boxes (trim/bleed/media/crop) and each page's content stream are resolved by walking the PDF's actual page tree (its /Kids structure), not by the order objects happen to appear in the file — those can differ a lot (a cover page added or edited last, for instance, can end up at a much higher object number near the end of the file despite being logical page 1). If that tree can't be resolved for some reason, the tool falls back to file-appearance order and marks affected pages "(approx.)" so it's clear the data may not be reliably aligned.
JPEG: color mode is read from the file's actual component data (RGB vs CMYK/YCCK), and resolution is read from embedded JFIF or Photoshop metadata when present.
PNG: flagged as RGB by definition — the PNG format has no CMYK mode at all, so any PNG placed into a CMYK print layout needs converting first. Resolution is read from the embedded pHYs chunk when present.
If no resolution metadata is embedded (common for plain exports), that's reported as "unverified," not a failure — confirm the intended print size manually.
Paper size: each page's finished size is checked against ISO 216 A/B series, ISO 269 C envelopes, US Letter/Legal/Tabloid, ANSI, and architectural Arch sizes, allowing for the larger of 2mm or 1% of rounding drift. This is informational, not a pass/fail check — a custom trim size is completely normal for packaging, posters, or die-cut work.
Very large or very long (100+ page) files take longer to scan, since image resolution and hairline checks now parse every page's actual content stream rather than just reading file-level metadata. Nothing about that scales with file size in a way that should cause browser crashes — image pixel data itself is never decoded — but it is more work than a purely structural scan.
