DEV Community: Rushikesh Lade

Stop Uploading Your Files to Random Websites: I Built a Privacy-First File Converter

Rushikesh Lade — Mon, 13 Jul 2026 18:43:11 +0000

Stop Uploading Your Files to Random Websites: I Built a Privacy-First File Converter

Every day, millions of people upload PDFs, images, Word documents, and other files to online tools without giving it a second thought.

Need to compress a PDF?

➡️ Upload it.

Need to convert a PNG to JPG?

➡️ Upload it.

Need to merge multiple PDFs?

➡️ Upload them all.

But have you ever stopped to ask yourself:

Where do those files actually go?

Most online file converters require you to upload your documents to their servers. While many services are trustworthy, you're still handing over personal files and relying on someone else's promise to delete them later.

That didn't feel right to me.

So I built FileForge Tools—a privacy-first collection of online file tools designed to keep your files where they belong: on your device.

🔒 Privacy Isn't a Feature—It Should Be the Default

The core idea behind FileForge Tools is simple:

If a file doesn't need to leave your computer, it shouldn't.

Whenever technically possible, file processing happens entirely inside your browser.

That means:

🔐 Your files stay on your device.
🚫 No unnecessary uploads.
⚡ Faster processing with no waiting for a server.
📱 Works across desktop and mobile.
👤 No account required.

For sensitive files like resumes, invoices, IDs, certificates, or personal photos, this makes a huge difference.

💡 Why Process Files in the Browser?

Modern web technologies have come a long way.

Using technologies like:

WebAssembly (WASM)
Modern JavaScript APIs
Browser-based file processing

many common file operations can now happen locally.

Instead of this:

Your Device → Internet → Server → Processing → Download

it becomes:

Your Device → Browser → Done ✅

No unnecessary middleman.

🛠️ What You Can Do

FileForge Tools currently includes utilities like:

📄 PDF tools
🖼️ Image conversion
📦 File compression
🔄 Format conversion
📑 Document utilities

I'm continuously adding more tools based on user feedback.

👨‍💻 Why I Built It

This started as a personal side project.

I wanted simple file tools that respected user privacy instead of treating uploads as the default solution.

The challenge was seeing how much modern browsers could do without relying on a backend server—and honestly, it's amazing how capable they are today.

The result is a faster, cleaner, and more privacy-conscious experience.

🚀 Try It Out

If you regularly work with documents, images, or PDFs and care about privacy, I'd love for you to give it a try.

👉 https://fileforgetools.in

I'm always looking for feedback from developers and users.

A few questions:

Which file tools do you use the most?
Have you ever hesitated before uploading sensitive files online?
What browser-based utility would you like to see next?

I'd love to hear your thoughts in the comments!

Final Thoughts

Privacy shouldn't be a premium feature.

It should be the standard.

The web has become powerful enough that many file operations no longer need a server at all—and I think that's a direction worth embracing.

If FileForge Tools saves you time or helps you keep your files private, then this project has accomplished exactly what I set out to build.

Thanks for reading! ❤️

How I Added Browser-Based HEIC to JPG Conversion (No Server, No Upload)

Rushikesh Lade — Sat, 11 Jul 2026 18:46:03 +0000

Every iPhone since iOS 11 saves photos as HEIC by default. It's a genuinely better format — same visual quality as JPEG at roughly half the file size, thanks to being built on HEVC compression instead of the decades-old JPEG codec. The problem is compatibility: plenty of websites, Windows apps, Android devices, and upload forms still can't open it. So "why won't this site accept my photo" is one of the most common small frustrations on the internet, and it's exactly the kind of problem a browser tool can solve without needing a server at all.

I just added a HEIC to JPG converter to FileForge Tools, my privacy-first file conversion site. Here's what building it actually involved.

Why this can't just be `<img src="photo.heic">`

Browsers don't natively decode HEIC. Safari can display HEIC images because Apple's OS-level codec handles it beneath WebKit, but that's not something JavaScript or the Canvas API can hook into directly — there's no ctx.drawImage() path from a raw HEIC buffer. You need an actual decoder.

That's what heic2any provides. Under the hood it's a WASM build of libheif that decodes the HEIC bitstream in-browser, hands you back a canvas-compatible image, and lets you re-encode it as JPEG (or PNG) at whatever quality you specify. The whole pipeline — decode, re-encode, download — happens in the browser's memory. Nothing is ever sent to a server.

const { default: heic2any } = await import("heic2any");

const result = await heic2any({
  blob: file,
  toType: "image/jpeg",
  quality: 0.9,
});

That's genuinely most of the API. The interesting parts were everything around it.

Batch conversion needs its own progress model

People rarely convert one HEIC photo — it's usually "I need to send my whole camera roll from this trip to someone on Windows." heic2any processes one file at a time, so batch conversion means a manual loop with per-file progress:

for (let i = 0; i < files.length; i++) {
  setProgress(`Converting ${i + 1} of ${files.length}…`);
  const out = await heic2any({ blob: files[i], toType: "image/jpeg", quality });
  // heic2any can return an array for multi-image HEIC containers — always handle both
  const blob = Array.isArray(out) ? out[0] : out;
  results.push({ name: files[i].name, blob });
}

That last line matters more than it looks — HEIC is technically a container format, and a single .heic file can hold multiple images (think burst shots). heic2any returns an array in that case, and if you don't check for it, you'll occasionally get [object Blob] written straight to a filename instead of an actual image.

Some HEIC files will fail, and that's fine

Not every file with a .heic extension decodes cleanly. Certain portrait-mode captures (which embed depth-map data alongside the image), some burst-photo variants, and HEIC files from non-Apple cameras use encodings the WASM decoder doesn't fully support. Rather than let a batch conversion silently produce a corrupt file or crash the whole loop, I wrapped each conversion individually:

try {
  const out = await heic2any({ blob: file, toType: "image/jpeg", quality });
  // ...
} catch {
  setError(`"${file.name}" could not be converted — it may use a HEIC variant this browser can't decode.`);
}

One bad file in a batch of twenty shouldn't take down the other nineteen. Fail loud on the one file, keep going on the rest.

Why this specifically needed to be client-side

Photos are a different privacy category from PDFs or JSON. A camera roll can carry faces, home addresses baked into EXIF GPS data, screenshots of private conversations, IDs — genuinely sensitive stuff, uploaded to convert a file format, of all things. Every other "HEIC to JPG" converter I checked uploads your file to a server first. For a task this mechanical, that's an unnecessary trust exercise.

Running the whole thing through WASM in the browser means the conversion is provably private — you can watch your network tab, or just go offline after the page loads, and it still works. That's the actual point of doing it this way, not just an implementation detail.

Try it

fileforgetools.in/heic-to-jpg — batch convert up to 20 photos, adjustable JPG quality, nothing uploaded.

Built with Next.js 14 on Vercel. If you're building anything with heic2any and hit the multi-image-array gotcha, hopefully this saves you the debugging session it cost me.

I Added PDF-to-Word, PDF-to-JPG, and PDF-to-PowerPoint to My Privacy-First File Tools Site

Rushikesh Lade — Sat, 11 Jul 2026 10:18:13 +0000

A few months ago I built FileForge Tools, a free site for everyday file conversions (image, PDF, text, dev utilities) that runs entirely in the browser. No file ever touches a server. This week I shipped the update I've wanted to build since day one: real PDF conversion tools.

What's new

PDF to JPG, every page of a PDF becomes a JPG image, with resolution and quality controls. Download pages individually or grab everything as a ZIP.

PDF to Word, extracts the text layer of a PDF into an editable .docx file. It reconstructs paragraphs from the PDF's positioned text data, and it explicitly detects and warns when a PDF is a scan with no selectable text (rather than silently producing garbage).

PDF to Google Docs, same conversion engine, but the page is written for the "I just need this open in Docs" search intent, with a quick guide for the Drive import step.

PDF to PowerPoint, renders each page at high resolution and drops it into a .pptx where the slide dimensions match your document's aspect ratio, so nothing gets stretched or cropped.

How it stays private

All four tools run on pdf.js in the browser, the same rendering engine Firefox uses for its built-in PDF viewer. The .docx files are built with the docx npm package, and the .pptx files with pptxgenjs. Everything happens in memory on your device; nothing is uploaded anywhere. You could disconnect your Wi-Fi mid-conversion and it'd still finish.

This did surface a genuinely annoying bundling problem worth sharing: pptxgenjs pulls in Node built-ins (fs, https) that don't exist in a browser. Webpack refused to bundle it until I added a NormalModuleReplacementPlugin in next.config.mjs to strip the node: scheme and fall back cleanly. If you're bundling pptxgenjs for the browser, that's the fix.

The other gotcha: pdf.js needs its standard font and cMap data files to render PDFs that reference fonts like Helvetica without embedding them (extremely common), or that use CJK character maps. Those normally live in node_modules, which a browser can't reach, so I copied them into /public/pdfjs/ and pointed standardFontDataUrl / cMapUrl at them. Skip this and you get silently broken glyphs on a chunk of real-world PDFs, not an obvious crash.

Also new: three guides

Converting a PDF to Word without losing formatting, and why complex layouts sometimes break
PDF to JPG: when it's the right call, resolution and quality settings explained
Presenting a PDF like an actual slide deck, PDF to PowerPoint, and when to use it over PDF to Word

Try it

fileforgetools.in/pdf-to-word · pdf-to-jpg · pdf-to-powerpoint

Built with Next.js 14, deployed on Vercel. Happy to answer questions about the pdf.js/webpack setup if anyone's fighting the same bundling issues.

How I Took a Site From 69 to 96 on PageSpeed by Fixing One Script Tag

Rushikesh Lade — Fri, 10 Jul 2026 17:19:44 +0000

I run a small Next.js site (free browser-based file conversion tools). Yesterday I ran PageSpeed Insights on mobile and got a 69 — "needs improvement," with First Contentful Paint at 4.0s and Largest Contentful Paint at 5.6s under slow-4G throttling. Today it's 96.

The fix took about five minutes once I found the actual cause.

The setup

Like a lot of small sites trying to monetize, I have a Google AdSense script in my root layout. It was added as a plain tag:

<script
  async
  src="https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js?client=ca-pub-xxxxx"
  crossOrigin="anonymous"
/>

async looks like it should be enough. It isn't — for what actually matters here.

What PageSpeed was actually flagging

The diagnostics called out "Reduce unused JavaScript — Est. savings of 186 KiB." That's a big number for a lightweight site. The twist: my AdSense account is still pending approval, so the script was loading its full weight and doing nothing — no ads were rendering yet. Pure cost, zero benefit, and it was still competing with my actual page content for parsing priority during initial load.

The fix

Next.js ships a purpose-built <Script> component specifically for this situation, with a strategy prop:

import Script from "next/script";

<Script
  src="https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js?client=ca-pub-xxxxx"
  strategy="lazyOnload"
  crossOrigin="anonymous"
/>

lazyOnload defers loading until the browser is idle, well after your actual content has painted. The script still loads — ads will still work once approved — it just stops competing with your page for the critical early-loading window.

Result

Performance: 69 → 96
The 186 KiB "unused JavaScript" flag: gone
Zero change to how AdSense actually functions

The takeaway

If you're running any third-party script (ads, chat widgets, analytics beyond the basics) as a raw <script> tag in a Next.js app, it's worth auditing. next/script's strategy prop has four options (beforeInteractive, afterInteractive, lazyOnload, worker) and picking the right one for non-critical scripts is close to a free performance win — no functionality lost, no removed features, just better loading priority.

For anything genuinely optional to the initial render — ads, chat bubbles, feedback widgets — lazyOnload is usually the right call.

How to Generate a Strong Password (And What Actually Makes One Strong)

Rushikesh Lade — Thu, 09 Jul 2026 08:14:10 +0000

A lot of password advice focuses on the wrong thing. Swapping an "a" for an "@" or adding an exclamation mark at the end feels like it's making a password stronger, but attackers' cracking tools have known these tricks for years, they barely slow anything down. Real password strength comes from two much simpler factors: length and true randomness.

Why length matters more than complexity tricks

Every extra character in a password multiplies the number of possible combinations an attacker would need to try. A random 8-character password might have around 50 bits of entropy, crackable by modern hardware in a practical amount of time. A random 16-character password with the same character variety jumps to roughly 100 bits of entropy, which is far beyond what's realistically crackable by brute force with current technology.

In other words, a long password made of ordinary lowercase letters is often stronger than a short password stuffed with symbols and substitutions. Length beats cleverness.

Why true randomness matters

The second ingredient is genuine randomness. Humans are bad at generating random-feeling passwords, we gravitate toward patterns, keyboard walks (like "qwerty123"), and personal references (birthdays, pet names) that feel random to us but are actually highly predictable to an attacker's cracking software, which is trained on exactly these patterns.

A password generator that draws from a cryptographically secure random source avoids this entirely. Every character is chosen independently with no underlying pattern, which is precisely what makes brute-force guessing infeasible.

What a good password generator should do

Use a cryptographic random source (like the Web Crypto API in a browser), not a simple pseudo-random function that could theoretically be predicted.
Let you set a meaningful length, 16 characters as a reasonable minimum, 20+ for anything important like a primary email or financial account.
Include a mix of character sets, lowercase, uppercase, digits and symbols, and guarantee at least one of each so the password meets typical site requirements.
Never transmit or log the generated password anywhere. A password generated in your browser and never sent over the network is inherently safer than one generated by a server you have to trust.

The part most people skip: using a password manager

Generating a strong password solves half the problem. The other half is not reusing it. A password manager lets you use a different, fully random, long password for every single account without having to remember any of them, you only need to remember one master password. This is genuinely the single biggest security improvement most people can make, and it's what makes long random passwords practical to use everywhere rather than just for your most important accounts.

I built FileForge Tools, 38 free file conversion and document tools that all run client-side, including a Password Generator using the Web Crypto API. No uploads, no accounts, no watermarks.

CSV to JSON: A Beginner's Guide

Rushikesh Lade — Thu, 09 Jul 2026 08:11:22 +0000

If you work anywhere near spreadsheets and code, you'll eventually run into this exact situation: someone hands you a CSV export from Excel or Google Sheets, and you need it as JSON for an API, a script, or a database import. Or the reverse, you have JSON and someone wants a spreadsheet.

It sounds like it should be trivial, and mostly it is, until your data has a comma inside a value, or a name with an apostrophe, or a blank cell, and suddenly your "quick conversion" is producing broken output. Here's what's actually going on under the hood, so you can do this reliably.

What CSV and JSON actually are

CSV (comma-separated values) is a plain text format for tables: one line per row, values separated by commas, and usually a header row naming each column. It's what you get when you export a spreadsheet as plain text.

JSON (JavaScript Object Notation) represents structured data as nested objects and arrays, the format nearly every API, config file, and modern app expects. A table of people in CSV becomes, in JSON, an array where each row is one object with the column names as keys.

The part that trips people up: quoting

CSV's one-comma-separated-line-per-row rule breaks the moment a value itself contains a comma, like a name written "Smith, Jane" or an address with a comma in it. The CSV standard handles this by wrapping such values in double quotes: "Smith, Jane". A naive converter that just splits every line on commas will incorrectly treat that quoted comma as a new column, silently shifting every value after it one column to the right.

A second, sneakier issue: what if a value itself contains a double quote? The standard says you escape it by doubling it, "She said ""hello""" represents the text She said "hello". Converters that don't implement proper CSV parsing (rather than a simple string split) will mishandle this too.

The other trap: numbers that aren't really numbers

CSV has no concept of data types, everything is just text. This causes a specific, easy-to-miss bug: a ZIP code like 01234 or a product code like 007 has a meaningful leading zero. If your converter automatically detects and converts number-looking values into actual JSON numbers, that leading zero silently disappears, 01234 becomes 1234, and now your ZIP code is wrong.

The safe default is to keep everything as text unless you specifically know a column is safe to convert, good tools give you this as a toggle rather than an automatic, all-or-nothing decision.

Doing it correctly

Use a converter that implements proper CSV parsing (quote handling, escaped quotes, embedded commas and line breaks) rather than a naive comma-split.
If your data has any column with meaningful leading zeros (ZIP codes, ID numbers), leave number detection off, or check the output carefully if you turn it on.
Check your delimiter, spreadsheets in some regional locales export with semicolons instead of commas. If your output looks like one giant column, this is usually why.
Spot-check a row or two of the output against the original, especially any row that had a comma or quote inside a value, that's where naive tools break first.

I built FileForge Tools, 38 free file conversion and document tools that all run client-side, including a proper CSV to JSON converter that handles all of this correctly. No uploads, no accounts, no watermarks.

JPG vs PNG vs WebP: Which Should You Actually Use?

Rushikesh Lade — Thu, 09 Jul 2026 08:05:57 +0000

Most people use whatever image format their phone, camera, or screenshot tool happens to save by default, without ever thinking about it, and most of the time that's fine. But if you've ever wondered why some images load faster than others, why a logo looks blurry after conversion, or why a colleague asked you to "send it as a PNG instead," the answer comes down to a genuine, practical difference between these three formats.

JPG: the default for photos

JPG uses lossy compression, meaning it throws away some detail the eye is least likely to notice in exchange for a much smaller file. For photographs, with their gradual color transitions and natural detail, this trade-off is usually invisible at normal viewing sizes, which is exactly why it's the default format for cameras and phones.

JPG's real limitation: no transparency support, and it handles sharp edges (like text or line art) poorly, compression artifacts show up as blurring or blocky patterns around hard edges, which is why a JPG screenshot of a document often looks slightly fuzzy around the text.

PNG: the default for screenshots, logos, and anything needing transparency

PNG uses lossless compression, every pixel is preserved exactly. This makes it the right choice for anything with sharp edges or flat colors: screenshots, logos, icons, and any graphic with a transparent background. The trade-off is size: a PNG of a photograph is typically much larger than the equivalent JPG, since lossless compression can't take advantage of the same detail-discarding tricks.

WebP: the modern all-rounder

WebP is a newer format that supports both lossy and lossless compression, plus transparency, essentially combining what JPG and PNG each do well into one format. A WebP photo at similar visual quality is typically 20-35% smaller than the equivalent JPG, and a WebP graphic with transparency is often 60-90% smaller than the equivalent PNG.

The only real limitation is compatibility with very old software that hasn't been updated to support it, but every current browser, and most modern image-editing tools, handle WebP natively. For anything destined for the web, it's now the better default over both JPG and PNG.

A simple decision guide

Photo, going on a website: WebP (fallback to JPG only for legacy compatibility needs)
Photo, need maximum compatibility with older software: JPG
Screenshot, logo, or icon with transparency, going on a website: WebP
Screenshot, logo, or icon, need maximum compatibility or a lossless master copy: PNG
Archiving an image you might edit further: PNG (lossless, so no quality is lost before you've even started editing)

I built FileForge Tools, 38 free file conversion and document tools that all run client-side, including converters between JPG, PNG and WebP. No uploads, no accounts, no watermarks.

How to Reduce a PDF's File Size for Email

Rushikesh Lade — Thu, 09 Jul 2026 08:03:19 +0000

It's a familiar moment: you attach a PDF to an email, hit send, and get an error saying the attachment is too large. Most email providers cap attachments somewhere between 20-25 MB, and it doesn't take much, a handful of scanned pages, or a report with a few embedded photos, to blow past that.

The fix depends on why the PDF is large in the first place, since a scanned contract and a report full of high-resolution photos need different approaches.

Why PDFs get this large in the first place

A PDF's size is almost always driven by the images inside it, scanned pages are essentially just full-resolution photographs of paper, and a report with several high-quality photos embeds all of that image data directly into the file. Text itself takes up very little space; a 50-page text-only PDF might be under a megabyte, while five scanned pages at high resolution can easily exceed 20 MB on their own.

If it's a scanned document

Scanned pages are usually scanned at a much higher resolution than needed for on-screen reading or even printing. If you have access to the original scanning software, rescanning at a lower DPI (150-200 is usually plenty for readable text) makes an enormous difference. If you only have the final PDF, look for a tool that can recompress the embedded images directly, since that reduces the size without needing to redo the scan.

If it's a document with embedded photos

Here the fix is more direct: reduce the size of the images before they go into the PDF. If you're the one assembling the document (for example, combining photos into a PDF for a report), compress each image first, cutting a photo from a phone camera down to reasonable web-viewing quality routinely shrinks it by 70-90% with no visible difference at normal viewing size, and the resulting PDF shrinks proportionally.

A practical workflow

If you're building the PDF yourself from photos, compress each image first (a tool set to 75-85% quality works well), then combine them into a PDF, this gives you far more control than compressing after the fact.
If you already have a large PDF and need to shrink it directly, look for a PDF compression tool that recompresses the embedded images, or split it into smaller parts if the whole document doesn't need to go in one email.
Check your email provider's actual limit before assuming compression alone will get you there, for very large scanned documents, sending a link to a shared file may be more practical than repeated compression.
Always keep your original, uncompressed file. Compression is one-directional, you can't get the lost detail back once you've shrunk it.

I built FileForge Tools, 38 free file conversion and document tools that all run client-side, including a PDF Compressor and Split PDF tool for exactly this problem. No uploads, no accounts, no watermarks.

How to Compress a PNG Without Losing Quality

Rushikesh Lade — Thu, 09 Jul 2026 08:00:51 +0000

PNG has a reputation for producing large files, and for good reason: it's a lossless format, meaning it stores every pixel exactly as it is, with no data thrown away. That's great for quality but often means a simple screenshot or logo ends up several megabytes in size, far bigger than it needs to be for how it will actually be used.

The trick to compressing a PNG well is understanding that you're not really "compressing" a PNG at all in the traditional sense, you're converting it to a smarter format that achieves a similar look at a fraction of the size.

Why you can't just 'compress' a PNG directly

PNG's compression is lossless and largely fixed, there's no quality slider because there's no quality to trade away. Every pixel is preserved exactly. That's precisely why PNG files can be so large: unlike JPG, which can throw away detail the eye barely notices, PNG has to represent everything faithfully.

The practical way to shrink a large PNG, then, is to re-encode it into a format that does support a quality trade-off, most commonly WebP or JPG, while keeping the visual result close enough to the original that nobody notices the difference.

WebP: the best option for most PNGs

WebP is the modern choice for shrinking PNGs, for one key reason: it supports transparency, just like PNG does, but with far more efficient compression. A logo, icon, or screenshot with a transparent background can typically be converted to WebP at 90%+ quality and come out 60–90% smaller than the original PNG, with no visible difference at normal viewing sizes.

This makes WebP the default recommendation for anything that started life as a PNG because it needed transparency or sharp edges, screenshots, icons, logos, UI mockups. You keep the exact same visual behavior, just in a dramatically smaller file.

When JPG makes more sense instead

If the destination absolutely requires maximum compatibility, an older system, a print shop, or a platform that doesn't accept WebP, JPG is the fallback. The catch is that JPG doesn't support transparency at all, so any transparent areas in your PNG get filled with a solid background color you choose. For a photo-like PNG with no transparency, this is a fine option; for a logo with a transparent background, it usually isn't what you want.

A practical workflow

Start with your original PNG, don't compress a copy that's already been compressed once, since starting fresh gives the cleanest result.
Choose WebP as the output format if the image has transparency or will only be used digitally.
Set the quality to around 90% as a starting point, this typically preserves fine detail and text while still shrinking the file substantially.
Compare the before and after file sizes. If the saving isn't enough and the image quality still looks fine, try lowering the quality a bit further.
Only fall back to JPG if the destination specifically can't accept WebP.

I built FileForge Tools — 38 free file conversion and document tools that all run client-side. No uploads, no accounts, no watermarks. Would love feedback if you try it out.

How to Merge PDF Files Without Uploading Them Online

Rushikesh Lade — Thu, 09 Jul 2026 07:57:37 +0000

If you've ever needed to combine a few PDFs, merging scanned receipts, stitching together a multi-part report, or combining signed contract pages, you've probably run into the same problem: most free "merge PDF" tools require you to upload your files to a server first.

For most documents that's a minor inconvenience. But if your PDFs contain anything sensitive, financial statements, medical records, signed agreements, ID scans, uploading them to an unknown third-party server is a real privacy risk, even if the site promises to "delete files after 24 hours."

The good news: your browser can do the entire job itself, with nothing ever leaving your device.

Why browser-based merging is different

Every modern browser (Chrome, Firefox, Safari, Edge) can read, combine and rebuild PDF files directly using JavaScript. When a tool is built this way:

Your files are read into your browser's memory, processed there, and the result is handed back to you as a download
Nothing is transmitted over the network, you could disconnect your Wi-Fi partway through and it would still finish
There's no server-side copy to worry about, no "we deleted it after 24 hours" trust required, and no risk of a data breach on someone else's infrastructure

The trade-off is that very large files (hundreds of megabytes) can be slower than a dedicated desktop app, since your browser is doing the work your computer's own memory allows. For everyday use, merging a handful of scanned pages or a multi-file report, it's fast and completely private.

Step-by-step: merging PDFs in your browser

Open a browser-based merge tool. FileForge's Merge PDF tool is a free option, no account, no upload.
Add your PDF files. Drag and drop them in, or click to choose files from your computer. You can add as many as you need, up to the tool's file-count limit.
Reorder if needed. Most merge tools let you drag files up or down in the list, this becomes the page order in your final PDF, so double check it before merging.
Click merge. Because everything happens locally, this is usually near-instant even for several files.
Download your combined PDF. The result is generated in your browser and saved straight to your downloads folder.

When you might still want a desktop app

Browser tools are great for occasional, single-session tasks. If you're merging PDFs constantly as part of a daily workflow, or need advanced features like adding page numbers, watermarks, or digital signatures across the merged file, a dedicated desktop PDF editor might serve you better long-term.

But for the common case, you just need a few PDFs combined into one, right now, without giving them to a stranger's server, a browser tool does the job with zero setup and zero privacy trade-off.

I built FileForge Tools, 38 free file conversion and document tools that all run client-side. No uploads, no accounts, no watermarks. Would love feedback if you try it out.

DEV Community: Rushikesh Lade

Stop Uploading Your Files to Random Websites: I Built a Privacy-First File Converter

Stop Uploading Your Files to Random Websites: I Built a Privacy-First File Converter

🔒 Privacy Isn't a Feature—It Should Be the Default

💡 Why Process Files in the Browser?

🛠️ What You Can Do

👨‍💻 Why I Built It

🚀 Try It Out

A few questions:

Final Thoughts

How I Added Browser-Based HEIC to JPG Conversion (No Server, No Upload)

Why this can't just be <img src="photo.heic">

Batch conversion needs its own progress model

Some HEIC files will fail, and that's fine

Why this specifically needed to be client-side

Try it

I Added PDF-to-Word, PDF-to-JPG, and PDF-to-PowerPoint to My Privacy-First File Tools Site

What's new

How it stays private

Also new: three guides

Try it

How I Took a Site From 69 to 96 on PageSpeed by Fixing One Script Tag

The setup

What PageSpeed was actually flagging

The fix

Result

The takeaway

How to Generate a Strong Password (And What Actually Makes One Strong)

Why length matters more than complexity tricks

Why true randomness matters

What a good password generator should do

The part most people skip: using a password manager

CSV to JSON: A Beginner's Guide

What CSV and JSON actually are

The part that trips people up: quoting

The other trap: numbers that aren't really numbers

Doing it correctly

JPG vs PNG vs WebP: Which Should You Actually Use?

JPG: the default for photos

PNG: the default for screenshots, logos, and anything needing transparency

WebP: the modern all-rounder

A simple decision guide

How to Reduce a PDF's File Size for Email

Why PDFs get this large in the first place

If it's a scanned document

If it's a document with embedded photos

A practical workflow

How to Compress a PNG Without Losing Quality

Why you can't just 'compress' a PNG directly

WebP: the best option for most PNGs

When JPG makes more sense instead

A practical workflow

How to Merge PDF Files Without Uploading Them Online

Why browser-based merging is different

Step-by-step: merging PDFs in your browser

When you might still want a desktop app

Why this can't just be `<img src="photo.heic">`