Tag: Privacy

  • Split PDF Online: Browser-Only, 100% Private [2026]

    Split PDF Online: Browser-Only, 100% Private [2026]

    TL;DR: Splitting a PDF means producing one or more smaller PDFs from a larger one — by page range (pages 1–10), every page (one file per page), every N pages, or by extracting specific page numbers. Our free PDF splitter runs pdf-lib entirely in your browser. Files never upload — important when splitting contracts, payslips, medical records, or anything you wouldn’t paste into a free upload-to-server tool.

    Splitting a PDF is the kind of task that feels small until you need to do it with a sensitive file. The default workflow — Google “split pdf” → upload to ilovepdf or smallpdf — sends your contract, salary sheet, or hospital record through a stranger’s server, where it sits in their cache for hours. For the same task, browser-only tools using pdf-lib (the JavaScript library that powers most modern PDF utilities) do the work locally with no data leaving your machine.

    Our PDF splitter handles the four common modes — page range, every page, every N pages, extract specific pages — with drag-and-drop input and one-click ZIP download for multi-file outputs. This guide explains exactly what each mode does, the technical limits, the privacy difference between browser and server splitters, and the gotchas with bookmarks and form fields.

    The 4 split modes — and which one you actually want

    Mode Output Best for
    Page range 1 file containing pages X–Y Extracting a chapter or section
    Per page N files, one page each Multi-page invoices, scanned receipts
    Every N pages ⌈N/k⌉ files of k pages each Splitting a long report into chapters
    Extract pages 1 file containing only the listed pages Pulling specific pages out of a deck
    Multi-range Multiple files, one per range Splitting a combined PDF into sections

    Privacy: browser-only vs server-based splitters

    Most “free PDF splitter” sites upload your file to their server, run the split there, and let you download the output. That means: your file sits in their cache for some retention period (often 24 hours, sometimes longer); their backups potentially preserve it; their privacy policy controls what happens to it. For a marketing brochure that’s fine. For a contract, payslip, medical record, signed legal document, or anything you’d email with care — it’s not.

    Our PDF splitter uses pdf-lib, a JavaScript library that runs entirely in the browser. When you drop a file in, the bytes never leave your tab. You can verify this in your browser’s Network tab — the file selection triggers zero outbound requests. The split files appear in your browser’s download folder via a local blob URL, not a server response.

    How to split a PDF in your browser

    1. Open the PDF splitter
    2. Drop your PDF into the upload zone, or click to pick a file
    3. Pick the split mode: Range, Per page, Every N pages, Extract, or Multi-range
    4. Type the page numbers (1-5, 8, 12-20 for multi-range)
    5. Click Split — output files appear immediately
    6. Click Download all (ZIP) for multi-file output, or download each file individually

    Technical limits and what to expect

    pdf-lib runs in WebAssembly and is fast for moderate-size PDFs:

    • Up to ~100 pages, mixed text and images: instant (under 1 second)
    • 100–500 pages with embedded fonts: 2–10 seconds
    • 500–1000 pages, scanned image-heavy: 10–60 seconds, may briefly stall the page
    • 1000+ pages or files over 200 MB: at the edge of browser memory; consider splitting in batches
    • Encrypted (password-protected) PDFs: require the password before splitting; pdf-lib supports both user and owner password

    Memory is the real limit. Mobile browsers are more restrictive than desktop — a 200 MB PDF that splits cleanly on a laptop may crash an iPhone Safari tab. For very large files, use the desktop browser or split in two stages.

    Common gotchas

    • Bookmarks and outlines. When you split a PDF, bookmarks pointing to extracted pages are preserved; bookmarks pointing to pages outside the new file are dropped. This is the correct behaviour but surprises people who expect the entire outline to follow.
    • Form fields. Interactive form fields (signature blocks, checkboxes, text inputs) on extracted pages keep their values. Fields on dropped pages are removed. Form-level metadata (default values, validation rules) is preserved at the document level.
    • Annotations and highlights. Comments, highlights, and stamps on extracted pages move with them. Annotations referencing dropped pages may show a broken link icon.
    • Linked TOCs break. A table of contents with hyperlinks to specific pages becomes partially broken when you split — half the links point to non-existent pages. Either remove the TOC or split before generating the TOC.
    • Output file names. Default naming is filename-part-N.pdf. Customise with the “Filename pattern” input — {name}-{from}-{to}.pdf tokens are supported.
    • Compression isn’t preserved by default. pdf-lib re-streams content; deeply-compressed input PDFs may grow ~5% in the output. To keep size down, run the output through a PDF compressor after splitting.

    When NOT to use this tool

    If you need OCR, deskewing, or text extraction, a PDF splitter won’t help — those are different workflows. For batch automation in a build pipeline, install pdf-lib locally (npm i pdf-lib) and write a Node script — same engine, more control. For PDFs with PDF/A archive compliance requirements, use Adobe Acrobat or PDF Studio Pro to preserve the compliance metadata; pdf-lib outputs standard PDFs that may not validate as PDF/A. For password-protected files where you don’t have the password, no tool will help — that’s the security working as intended.

    Frequently asked questions

    Is my PDF uploaded?

    No. The splitter uses pdf-lib running in your browser. The file is loaded into a blob URL in your tab, processed locally, and the output is generated from the same in-memory data. You can verify in DevTools’ Network tab: dropping a file produces zero outbound requests.

    What’s the largest PDF I can split?

    Effectively your browser’s available memory. On desktop, files up to 200 MB and 1,000+ pages work. On mobile, the practical limit is around 50 MB. If a split fails, refresh the tab to free memory and try again with a smaller batch.

    Can I split a password-protected PDF?

    Yes — paste the user password in the prompt that appears when you upload. The splitter handles both user passwords (open access) and owner passwords (edit access). Password-protected files where you don’t know the password cannot be split — that’s the encryption working correctly.

    Does the split preserve form fields and signatures?

    Form fields and electronic signatures on extracted pages are preserved. Fields and signatures on dropped pages are removed (they wouldn’t be valid in the smaller file anyway). Visible certificate-based signatures from Adobe or DocuSign keep their visual representation; cryptographic validity depends on whether the signed scope changed.

    How do I split a PDF into individual pages?

    Pick the “Per page” mode. A 30-page input becomes 30 single-page output files in a ZIP. Useful for archiving multi-page invoices into one file per invoice, or pulling each scanned receipt out of a batch capture.

    Will splitting reduce the file size of each part?

    Roughly proportional to page count — splitting a 30 MB / 30-page PDF into 3 files yields three ~10 MB files. Embedded fonts and images are included only in the parts that reference them, so files with shared graphics may be slightly smaller than 1/N. To shrink further, run each output through a PDF compressor.

    Related tools and guides

     

  • Blur Face Online: Photo Censor in Browser [2026]

    Blur Face Online: Photo Censor in Browser [2026]

    TL;DR: A photo censor tool covers sensitive parts of a photo — faces, license plates, addresses, screen content — with one of three opaque overlays: pixelation (mosaic blocks), gaussian blur, or black bar. Use a black bar for legal redaction, pixelation for casual face blurring, blur only when readability of the underlying region doesn’t matter. Our free photo censor runs in your browser, supports all three modes, and strips EXIF metadata from the export so location and camera data don’t leak.

    Posting a photo online without thinking about who’s in it has become a privacy concern even for casual users. A vacation snap shows a stranger’s child clearly enough to identify them. A street photo includes a license plate. A screenshot of a calendar exposes a colleague’s home address. The fix is mechanical: cover the sensitive region with an opaque overlay before publishing. Done in two minutes; the alternative is removing the photo after someone complains.

    Our photo censor handles all three common censoring modes — pixelate, blur, black bar — and lets you brush, drag a rectangle, or click a face for an automatic ellipse. Files never upload — the photo loads into your browser, gets edited locally, and exports with EXIF metadata stripped. This guide covers when to use which mode, the irreversibility of pixelation vs blur, and the photographic gotchas (low-resolution faces, low-blur radius) that have leaked private information in the past.

    Censor mode comparison — and which to actually use

    Mode Reversible? Best for
    Black bar No Legal redaction, license plates, sensitive text
    Pixelate (block 12+) No (irreversible at high enough block size) Faces in social photos, casual blurring
    Gaussian blur Partially (low blur is recoverable) Aesthetic blurring where a black bar would clash
    Solid color No Branded redactions, dark backgrounds
    Sticker / emoji overlay No Casual social posts, fun reveals

    The pixelation problem — when blurring isn’t enough

    Light pixelation can be reversed. Researchers at Cornell in 2016 demonstrated that “mosaic” pixelation with a small block size can be reverse-engineered using machine learning to identify the original face — particularly if you have other photos of the same person to train on. The defence is simple: use a large enough block size that the original information is genuinely destroyed.

    • Block size 4–8: trivially reversible. Don’t use for privacy.
    • Block size 12–18: safe for casual social posts; very hard to reverse without targeted ML.
    • Block size 24+: unrecognisable; safe for sensitive contexts.
    • Black bar: impossible to reverse — the data is gone, not blurred.

    For genuinely sensitive content (legal redaction, evidence handling, witness protection), use a black bar. For “I don’t want this person identified by a casual viewer”, pixelation at block 18 is enough.

    How to censor a photo in your browser

    1. Open the photo censor
    2. Drop your image (JPG, PNG, WebP, HEIC supported)
    3. Pick a mode: Pixelate, Blur, Black bar, Color block, or Sticker
    4. Use the rectangle tool, brush, or “click to detect face” mode to select the region
    5. Adjust block size or blur radius — preview updates live
    6. Click Export. The exported image has EXIF metadata stripped (no GPS, camera serial, or timestamp)

    EXIF metadata — the hidden privacy leak

    Every JPG and HEIC photo from a phone or camera includes EXIF metadata: latitude/longitude (if location was on), camera model, lens, exposure settings, sometimes the camera’s serial number. A photo posted to a forum or sent in an unencrypted message can leak the exact GPS coordinates of where it was taken. Pixelating a face does nothing about EXIF.

    Our exporter strips EXIF by default — the saved image has no location, no camera serial, no timestamp beyond the file’s own modified time. If you want to keep EXIF (e.g. for archival), toggle “Preserve EXIF” before export. Most platforms (Twitter, Discord, Reddit) strip EXIF on upload anyway; some (Slack file shares, email attachments, direct downloads) do not.

    Common gotchas

    • Low-resolution selections leak through pixelation. If your photo is 4000×3000 and the face is 200×200 pixels, pixelation at block 18 turns that face into 11×11 visible blocks — recognisable to anyone who knows the person. Use block 24+ or scale up the source image first.
    • Reflections and shadows. Censoring a face but leaving a reflective surface (window, mirror, sunglasses) where the face is also visible defeats the purpose. Censor every visible instance.
    • Tattoos, scars, and unusual clothing identify people. A face-blurred photo where the subject has a distinctive tattoo or coat is still identifiable to anyone who knows them. Consider blurring or cropping those features too.
    • License plates have a smaller resolution than faces. A car plate at 80×30 pixels needs a smaller block size to look natural while still being unreadable — block 6–8 typically. Blurring a plate by mistake at face-block-size washes out the whole car.
    • Screen content reflected on a face. Photos of someone looking at a phone often reveal app content reflected on their glasses. The pixelation needs to cover both the screen and the eyes.
    • Don’t rely on overlay alpha. A semi-transparent blur overlay still passes through detail. Use full-opacity overlays for any actual privacy protection.

    Legal context: when redaction is required

    Several scenarios require censoring before publication:

    • EU GDPR: photos showing identifiable people require their consent for publication — censoring removes the identifiability.
    • HIPAA (US healthcare): patient photos must redact 18 specific identifiers including face, full-body view, distinctive marks, and any identifiers in background text.
    • Court-ordered redaction: evidence photos in some jurisdictions must redact identifying information of minors, witnesses, or jurors.
    • Press ethics: news organisations often blur the faces of bystanders, accident victims, and minors — a black bar or full pixelation, never a thin blur.

    For any legal-grade redaction, use the black bar mode. Pixelation is partial protection at best; lawyers and regulators want the data gone, not just hidden.

    When NOT to use this tool

    For redacting text in PDFs, use a PDF-aware redaction tool — pixelating text in a PDF doesn’t remove the underlying text from the PDF stream, so the redacted text is recoverable by anyone with a PDF reader. For batch automation (censoring 100s of photos with the same regions), use a Python script with OpenCV or Pillow. For video face-blurring (e.g., bystanders in a YouTube vlog), use a video editor with face-tracking — this tool is for static images only.

    Frequently asked questions

    Is pixelation reversible?

    Light pixelation (block 4–8) can be reverse-engineered using ML models, especially if other photos of the same subject exist. Block 18+ is safe for social use; block 24+ is unrecognisable. For genuinely sensitive content (legal redaction), use a black bar — the underlying data is gone, not just hidden.

    Does censoring strip EXIF data?

    Yes by default — the exported image has no GPS coordinates, camera serial, or original timestamp. Toggle “Preserve EXIF” before export if you want to keep that metadata (rare; usually a privacy mistake).

    Can I use this for legal redaction?

    For legal-grade redaction, use the black bar mode — the underlying pixel data is replaced, not transformed. Pixelation and blur are partial protections at best. Always check with a legal professional for high-stakes redaction (court evidence, regulated healthcare records).

    What’s the difference between blur and pixelate?

    Blur smooths the region using a gaussian filter; pixelate replaces it with a mosaic of solid blocks. Blur looks more natural in photos; pixelate looks more “censored” but is harder to reverse-engineer at high block sizes. For privacy, pixelate at block 18+ wins; for aesthetic blurring, gaussian blur looks better.

    Is my photo uploaded?

    No. The censor runs in your browser using the canvas API. The photo is loaded into a blob URL in your tab and never leaves your device. The exported image is generated locally — you can verify with DevTools’ Network tab.

    Can the tool detect faces automatically?

    Yes — toggle “Auto-detect faces” and the tool runs an in-browser face detection model on the image. Detected faces appear as ellipses you can accept, edit, or remove. Detection is good but not perfect; always verify each face is covered.

    Related tools and guides

     

  • Make PDF Look Scanned: Browser-Only Converter [2026]

    Make PDF Look Scanned: Browser-Only Converter [2026]

    TL;DR: A “scanned PDF converter” makes a clean digital PDF look like it came out of a real scanner — adds skew (slight rotation), paper grain, faded ink, edge shadows, and downsamples to 96–150 DPI. Used for forms that demand “scanned” submissions, courtesy submissions where a printout-and-rescan would be the official process, and for visual consistency in workflows that mix scanned and digital documents. Our free scanned PDF converter runs entirely in your browser using pdf-lib + canvas filters.

    The “please submit as a scanned PDF” requirement is one of the small absurdities of digital paperwork. A perfectly valid digital signature is rejected by an HR system that still parses scanned forms only. A government portal expects an “ink-on-paper” feel even though the form was filled in Word. Some e-discovery systems flag clean PDFs as suspicious because they assume real submissions go through a copier. The fix: take your clean digital PDF and run it through filters that mimic the artefacts of a real scan — grain, skew, faded edges, slightly off-white paper.

    Our scanned PDF converter applies five effects in combination: skew (random ±2° rotation per page), grain (paper texture noise), ink fade (slight contrast reduction), edge shadow (vignetting from the scanner glass), and resolution downsample (rasterise to 150 DPI). The result passes most “looks scanned” detectors without any of the security concerns of uploading sensitive forms to an unknown server. This guide covers each effect, when to use this for legitimate workflows, and the legal grey areas to avoid.

    The 5 effects and what each fixes

    Effect Tells it fixes Default value
    Skew Perfectly aligned page edges ±1.5° rotation per page
    Paper grain Pixel-perfect text and uniform background 8% noise, low contrast
    Ink fade Pure black text, 100% saturation Reduce contrast 12%, RGB shift to #1a1610
    Edge shadow Razor-sharp page boundaries 12px gradient at edges, 30% opacity
    Resolution Vector-perfect text rendering Rasterise to 150 DPI
    Paper tint Pure white background #fdfaf2 (off-white)
    JPG compression Sharp PNG-grade quality JPG quality 80, slight blocking

    Three intensity presets

    Most users don’t need to tune individual sliders. The presets cover 95% of cases:

    • Light: subtle grain and skew, retains text crispness. For legitimate forms where the scanned look is a courtesy.
    • Medium (default): noticeable grain, ink fade, edge shadow. The “honest scan” preset.
    • Heavy: aggressive aging — strong grain, brown paper tint, more skew. For documents you want to look old or photocopied many times.

    Pick a preset, preview the first page, adjust if needed.

    How to make a PDF look scanned

    1. Open the scanned PDF converter
    2. Drop your PDF in
    3. Pick a preset: Light, Medium, or Heavy
    4. Adjust skew amount, grain intensity, paper tint, and resolution if needed
    5. Click Convert. Each page is rasterised, processed, and re-embedded
    6. Download the converted PDF — typically 2–4× the original file size due to raster pages

    Legitimate uses (and the line you shouldn’t cross)

    Legitimate:

    • Forms that demand a “scanned” submission for visual consistency (HR forms, some legal templates, some government portals)
    • Submitting a digital fill of a form designed to be printed-and-scanned
    • Visual consistency in mixed scanned/digital archives
    • Mock-ups for UI design (e.g., showing what a scanned doc looks like in a doc-management UI)
    • Educational examples of OCR pre-processing

    Don’t:

    • Forge documents — making a fake invoice “look scanned” to deceive someone is fraud, regardless of whether you used Photoshop or this tool
    • Pass off a generated document as having gone through a paper original — for any document that requires a wet-ink signature, use one
    • Strip metadata to hide the original source from a fraud investigation
    • Manipulate evidence — adding “scanned” artifacts to a document submitted in legal proceedings is evidence tampering

    The tool is for honest workflows. If your use case requires the recipient to believe the file went through a paper-and-scanner pipeline that it didn’t, you’re in fraud territory.

    Common gotchas

    • File size grows. Rasterising vector pages to images (even at 150 DPI) typically 2–4× the original file size. A 1 MB digital PDF becomes 2–4 MB scanned-look output. Run through a PDF compressor after if size matters.
    • Text becomes uncopyable. The output is image-based — selecting text returns nothing. Most workflows treat that as a feature (real scans are also image-based until OCR). If you need selectable text, don’t run this conversion.
    • Search engines and accessibility tools can’t read it. A converted PDF has no machine-readable text — which is fine for forms but bad for archival. Keep the digital original.
    • Skew direction. Use random ±skew per page, not constant ±skew. A constant tilt looks like a misaligned scanner, not a stack of slightly-misfed pages.
    • Paper colour. Pure white (#FFFFFF) is the giveaway — real scans land on slightly off-white because of paper colour, ambient light, or scanner sensor calibration. Even at “Light” preset we tint to #fdfaf2.
    • Line art. CAD drawings and line-art-heavy documents can look damaged after grain + downsample. Test before processing technical drawings.

    When NOT to use this tool

    For documents that require legal authenticity (contracts, medical records, court filings), skip the conversion — submit the original PDF if possible, or scan a printed copy of the wet-signed version. For OCR or text extraction, the conversion makes things worse, not better — keep the digital original. For batch processing (100s of files at scanned-look output), install pdf-lib + sharp locally and script the conversion. For sensitive material where even browser processing is too risky, use offline software like ImageMagick on an air-gapped machine.

    Frequently asked questions

    Why would I want to make a PDF look scanned?

    Forms that demand “scanned” submissions for visual consistency, government portals that flag clean PDFs, HR systems that only accept scan-style files, and visual consistency across archives that mix scanned and digital documents. Always for honest workflows — fabricating documents to deceive someone is fraud regardless of the tool.

    Will the converted PDF still have selectable text?

    No. The conversion rasterises each page, so the output is image-based. Selecting text returns nothing. Most workflows that demand “scanned” PDFs expect this — real scans are also image-based until OCR is applied. If you need selectable text, don’t run this conversion.

    How much does the file size grow?

    Typically 2–4× the original. A 1 MB digital PDF becomes 2–4 MB after raster conversion at 150 DPI. Run the output through a PDF compressor if size matters — a moderate compression brings it back close to the original size while keeping the scanned look.

    Is this legal?

    The tool itself is legal everywhere. The output’s legality depends on use. Submitting a converted file to a workflow that demands “scanned” format for visual consistency is fine. Using it to forge documents (fake invoices, fake official records) is fraud regardless of the tool.

    Is my PDF uploaded?

    No. The converter runs in your browser using pdf-lib + canvas. The file loads into a blob URL and never leaves your tab. You can verify in the Network tab — zero outbound requests after upload.

    Can I undo the conversion?

    No — once rasterised, the original vector text is gone. Always keep your digital original in a separate file. The converted file is a one-way derivative, not a wrapper around the original.

    Related tools and guides

     

  • PDF Merger Tool: Combine PDFs in Your Browser [2026 Guide]

    PDF Merger Tool: Combine PDFs in Your Browser [2026 Guide]

    TL;DR: A PDF merger tool combines multiple PDF files into one, in the order you choose. Our browser-based PDF merger drops, reorders, and merges entirely on your device — no upload, no signup, no file size cap. Text stays searchable, fonts stay embedded, and the merged file is structurally identical to running pdftk cat from the command line. For most office workflows (contract packages, signed-document stacks, multi-source reports), this is the fastest workflow you can build.

    Every office worker hits the same wall once or twice a month: the contract is in two PDFs, the signature page is in a third, the appendix arrived as a separate email attachment, and the recipient wants one file. PDF merging is the mundane plumbing of business workflows — boring, frequent, and easier with the right tool than people realise. The catch is that the most popular cloud-based mergers upload your file to their servers, which is the wrong default for contracts, signed documents, medical records, or anything containing PII.

    Our PDF merger tool runs entirely in your browser using pdf-lib — the same JavaScript PDF library that powers many enterprise document pipelines. Drop your PDFs, reorder them with arrow buttons, click merge. The output downloads to your device. Nothing transmits. This guide explains how PDF merging actually works under the hood, what gets preserved vs lost during the merge, and the workflow tricks that make merging fast for repeat tasks.

    What does PDF merging actually do to the file?

    A PDF is a tree of objects — pages, fonts, images, metadata, structural elements — referenced by a cross-reference table. Merging two PDFs concatenates the page lists from each source while copying every referenced object (fonts, images, etc.) into the output’s object table. The result is a single PDF whose pages appear in the order you specified, with no quality loss because no pixel data is recompressed.

    Element What happens during merge
    Pages Concatenated in your specified order. No re-rendering.
    Text content Fully preserved. Searchable, selectable, and copy-pasteable in the merged file.
    Fonts Embedded fonts from each source are copied. If the same font appears in multiple sources, it’s deduplicated.
    Images Preserved at original quality. No recompression.
    Hyperlinks Preserved per-page. Internal links that pointed within the original PDF still work.
    Bookmarks / TOC Most browser-based mergers strip these. Heavyweight tools (Acrobat, PDFsam) preserve and renumber.
    Form fields Preserved. If two PDFs have fields with the same name, behavior is undefined — rename in source first.
    Digital signatures Invalidated. Signatures cryptographically sign the entire file’s bytes; merging changes those bytes.
    Metadata (title, author, etc.) Inherited from the first PDF in the list, or blank if our tool’s metadata-strip default is on.

    The signature gotcha matters for legal workflows. If you’re merging a digitally-signed contract with an appendix, the merged file no longer carries the signature’s cryptographic validation — opening it in Acrobat shows the signature as “invalid” because the document hash has changed. Workflow: merge first, then sign the combined file, or keep signed documents separate and bundle them in a ZIP.

    The five workflows people actually use a PDF merger for

    • Contract package assembly. NDA + master agreement + statement of work + signature page = one deliverable. Reorder so the cover page is first, signature page last. The most common business use case.
    • Receipts and expense reports. Combine 12 individual receipt PDFs into a single end-of-quarter expenses document. Saves the 12-attachment email and gives accounting one file to file.
    • Multi-source research bundle. Three articles, two slide decks exported as PDF, one transcript — one master read-pack for the team. Order matters here: put the executive summary first.
    • Email + attachments archive. Many email clients let you “print to PDF” both the message and its attachments. Merging produces a single permanent record. Useful for legal discovery and personal archiving.
    • Scanned document stacking. A scanner that produces one PDF per page (still common in older office machines) leaves you with 30 single-page PDFs after a long scan job. Merge produces the document you actually wanted.

    For each use case, the order of the source PDFs matters. Spend a moment with the up/down arrows before clicking merge — fixing order after the fact requires splitting + remerging, which is more work than getting it right the first time.

    How to use the browser PDF merger

    1. Open the PDF merger tool
    2. Drop your PDFs onto the dropzone, or click to pick files. Multiple selection works on every modern OS
    3. Each file appears in a list with its filename and page count
    4. Use the up / down arrow buttons to reorder. The order in the list is the order in the merged output
    5. Trash icon removes any file you don’t want included
    6. The total page count for the merged file shows above the list — sanity-check before merging
    7. Click Merge. The merged PDF downloads as merged-{timestamp}.pdf

    Everything happens locally — when you select a file, the browser reads it, parses the page count, and discards it from memory after merge. No copy is sent to our servers. The 100MB+ practical ceiling is your browser’s RAM, not a server-side cap. Most laptops handle hundreds of source PDFs at a time without issue.

    Cloud merger vs browser merger — the privacy trade-off

    The PDF merger market is split between cloud-based services (iLovePDF, Smallpdf, Adobe Acrobat online) that upload your file to their servers and process it there, and browser-based tools (ours, Drawboard, PDFsam in its desktop form) that process locally. The trade-off:

      Cloud merger Browser merger
    Speed Fast for huge files (server CPU) Limited by your device
    File size limit 10-50MB typical free tier Limited by browser RAM (~200-500MB)
    Bookmark preservation Usually yes Usually no (pdf-lib doesn’t preserve)
    Privacy File uploaded, retained briefly per privacy policy Never leaves your device
    Internet required? Yes, for entire operation Only for first page load
    Right for Public PDFs, marketing assets Contracts, medical, legal, anything sensitive

    For an offsite training PDF you’re combining with the public schedule, cloud is fine. For a draft NDA being merged with a tax return for a property purchase, never upload — privacy isn’t a policy promise on a help page; it’s the architecture of where the bytes go. Browser-based merging gives you architectural privacy.

    Merging PDFs in code

    For automated pipelines — say, monthly receipt-bundle generation or batch document assembly — a script beats clicking. Each environment has a mature library.

    Python (pikepdf — fastest, lossless):

    import pikepdf
    from pathlib import Path
    
    merged = pikepdf.Pdf.new()
    for path in sorted(Path("inputs").glob("*.pdf")):
        src = pikepdf.Pdf.open(path)
        merged.pages.extend(src.pages)
    merged.save("merged.pdf")

    Node.js (pdf-lib — the same library our browser tool uses):

    import { PDFDocument } from "pdf-lib";
    import { readFile, writeFile } from "node:fs/promises";
    
    const merged = await PDFDocument.create();
    for (const file of ["a.pdf", "b.pdf", "c.pdf"]) {
      const bytes = await readFile(file);
      const src = await PDFDocument.load(bytes);
      const pages = await merged.copyPages(src, src.getPageIndices());
      pages.forEach((p) => merged.addPage(p));
    }
    await writeFile("merged.pdf", await merged.save());

    qpdf (CLI — fastest for very large jobs):

    # Merge in alphabetical order
    qpdf --empty --pages *.pdf -- merged.pdf
    
    # Merge specific files in specific order
    qpdf --empty --pages a.pdf b.pdf c.pdf -- merged.pdf
    
    # Preserve bookmarks (qpdf does this by default; some libraries don't)
    qpdf --empty --pages a.pdf 1-5 b.pdf 1-z -- merged.pdf

    Ghostscript (CLI — slowest but recompresses + may shrink output):

    gs -dBATCH -dNOPAUSE -q -sDEVICE=pdfwrite \
       -sOutputFile=merged.pdf a.pdf b.pdf c.pdf

    Choose by goal. pikepdf and pdf-lib are lossless and fast — same approach as our browser tool. qpdf is the most powerful for complex page-range merges and preserves bookmarks. Ghostscript re-encodes everything (slower but can produce smaller files because it consolidates duplicated objects across sources). For most workflows, pikepdf or pdf-lib is the right answer.

    Merging password-protected PDFs

    Browser-based mergers can’t read encrypted PDFs without the password — pdf-lib loads encrypted documents only if you pass the password explicitly, and our tool doesn’t expose that field by design. Three options when one of your sources is password-protected:

    • Decrypt first, merge second. Open the encrypted PDF in Adobe Acrobat (or qpdf with --decrypt), save an unencrypted copy with a different filename, then merge. Delete the unencrypted copy after the merge if the password protected sensitive content. Don’t share the unencrypted intermediate file.
    • Use qpdf at the command line. qpdf --password=secret --decrypt encrypted.pdf decrypted.pdf, then merge with the steps above. Direct enough that the password never leaves your terminal session.
    • Skip the encrypted source. If the encryption is meaningful (PII, financial data), think hard before merging — a single combined unencrypted file is now your weakest-link risk. Consider keeping the documents separate and bundling them in a password-protected ZIP instead.

    Common mistakes that produce bad merges

    • Wrong page order. The list order in the tool is the merge order. Always sanity-check the order before clicking merge — fixing it post-merge requires splitting and remerging.
    • Mixing landscape and portrait pages without thinking. The merged PDF will display them in their original orientations, which can read as inconsistent. Either rotate problem pages first (some PDF tools have a rotate option, or use qpdf --rotate) or accept the mixed orientation if it’s fine for your reader.
    • Merging across versions of the same document. If you have v1 and v3 of a contract and accidentally merge both, the result is two confusingly-similar copies. Always rename or archive old versions before assembling a deliverable.
    • Forgetting that signed PDFs lose signatures on merge. Sign the merged file, not the components, when you need a single legally-binding document.
    • Merging huge files all at once on a low-memory device. 50 source PDFs at 20 MB each requires 1 GB of free browser RAM minimum. If your device is tight, merge in batches (10 PDFs first, then 10 more, etc.) rather than all at once.

    When NOT to merge PDFs

    • Legal exhibits. Court filings often require each exhibit to remain a separate file with its original filename. Merging changes the file’s identity for evidence purposes. Check the local rules before combining.
    • Already-digitally-signed contracts. Merging invalidates the signature. If the signature is the whole point of the document, keep it separate.
    • Different access-control documents. A confidential financial statement merged with a public marketing PDF inherits the most-permissive distribution permissions automatically. Keep different sensitivity levels separate.
    • Documents whose order changes by audience. If you sometimes need the appendix first and sometimes last, keep the parts separate and merge fresh per audience.
    • Files that exceed 100MB total. Browser memory becomes the bottleneck. Use qpdf or pikepdf locally instead.

    Frequently asked questions

    Does merging PDFs reduce their quality?

    No. PDF merging copies pages and embedded resources without re-encoding any content. The merged file is byte-for-byte equivalent to the source pages — text stays searchable and selectable, images retain their original quality, fonts render the same. The only thing that changes is the file’s metadata and structural elements (cross-reference table, object IDs).

    Is there a limit on how many PDFs I can merge?

    The browser tool’s limit is your device’s RAM, not a fixed file count. Merging 50 small office PDFs is trivial; merging 50 image-heavy 20MB PDFs needs about 1 GB of free browser memory. For very large jobs (hundreds of PDFs, gigabytes of total size), use a command-line tool like qpdf or pikepdf locally, which streams the merge rather than loading everything into memory.

    Will the merged PDF be searchable?

    Yes — text content, hyperlinks, and form fields all survive merging. If a source PDF was searchable before, those pages are searchable in the merged output. If a source was a scanned image-only PDF without OCR, those pages remain image-only in the merge. To make scanned pages searchable, run OCR (Adobe Acrobat, tesseract, ABBYY FineReader) before or after merging.

    Are bookmarks preserved when I merge?

    In our browser tool, no — pdf-lib (the underlying library) doesn’t preserve bookmarks across merges. If your workflow needs combined bookmarks (think long technical reports with TOCs), use Adobe Acrobat, PDFsam Basic, or qpdf at the command line — all three preserve and renumber bookmarks during merge.

    Can I merge a PDF with a Word document or image?

    Not directly. PDF mergers only accept PDF input. Convert other formats first: print Word documents to PDF (built into Word and Google Docs), or use an image-to-PDF tool to wrap photos and scans into PDF format. Then merge as usual.

    Is my PDF uploaded when I use the merger?

    No. The browser reads your PDF locally via the File API, parses it with pdf-lib, performs the merge in JavaScript, and offers the result as a download — all without making any network requests. Verify by opening Chrome DevTools → Network tab and watching for upload requests when you click merge: there are none.

    Related tools and guides

     

  • Strong Random Password Generator: NIST-Aligned & Secure

    Strong Random Password Generator: NIST-Aligned & Secure

    TL;DR: A strong random password generator uses your browser’s Web Crypto API (crypto.getRandomValues) to produce passwords from genuine OS-level entropy, not predictable Math.random(). Aim for at least 80 bits of entropy — that’s roughly 16 mixed-case alphanumeric characters or a 6-word passphrase. Our free generator does both and shows you the entropy live, so you can see exactly how strong each output is.

    The fundamental rule of password security has changed quietly: NIST’s 2024 update (SP 800-63-4) prohibits forcing users to mix uppercase, lowercase, digits, and symbols. The reason is empirical. Forced complexity rules produced more predictable passwords, not stronger ones — users picked the same dozen tricks (capitalise the first letter, replace o with 0, add ! at the end) and attackers learned them years ago. The new guidance: length is what matters. A 16-character lowercase-only password has more entropy than an 8-character password using the full ASCII set.

    Our strong random password generator implements this guidance. It defaults to 20 characters with the full mixed-case alphanumeric+symbol pool, computes the entropy live, and runs entirely in your browser using the Web Crypto API — your password never travels to any server. This guide explains the math behind password strength, why Math.random() is dangerous, the three modes (random, pronounceable, passphrase) and when to use each, and the storage workflow that keeps strong passwords actually usable.

    Why password entropy matters more than complexity

    Password strength is measured in bits of entropy. A password with N bits of entropy means an attacker needs to try up to 2^N combinations to crack it by brute force. The math is simple: each character drawn at random from a pool of P characters contributes log₂(P) bits.

    Character pool Pool size Bits per character
    Lowercase only (a-z) 26 4.7
    Lower + upper (a-z, A-Z) 52 5.7
    Lower + upper + digits 62 5.95
    Lower + upper + digits + symbols ~94 6.55

    Multiply bits-per-character by length to get total entropy. The threshold to remember:

    • Under 40 bits: weak. Crackable in minutes-to-hours by a modern GPU farm against any common password hash.
    • 40-60 bits: moderate. Survives casual attacks but falls to determined attackers within days against fast hashes (MD5, SHA-256).
    • 60-80 bits: strong. Beyond practical brute force for any single attacker; survives most state-of-the-art GPU farms for years.
    • 80+ bits: excellent. Requires nation-state computational resources and decades of work. NIST’s recommended floor for high-security passwords.