DEV Community: Rushikesh Lade

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.