DEV Community: Vijay Kanna

Why Your SVGs Are Bigger Than They Need to Be (And What's Actually Bloating Them)

Vijay Kanna — Tue, 28 Jul 2026 02:29:34 +0000

Export an icon from Figma or Illustrator and you'll usually get an SVG that's 3–5x larger than it needs to be. Not because SVG is inherently bloated — it's a genuinely efficient format — but because design tools leave a trail of editor metadata, redundant precision, and unused structure that never gets cleaned up before it ships to production.

Here's what's actually taking up the space, and why "just minify it" is doing more specific work than that phrase suggests.

What's Actually in a "Bloated" SVG

Take a simple two-circle icon — the kind of thing that should realistically be under 200 bytes:

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 100 100" width="100" height="100">
  <!-- Author: Design Tool Export -->
  <g id="Background">
    <rect width="100" height="100" fill="#f5f3ff" rx="15" />
  </g>
  <g id="AccentCircle">
    <circle cx="50" cy="50" r="30" fill="#6366f1" opacity="0.15" />
    <circle cx="50" cy="50" r="20" fill="#4f46e5" />
  </g>
</svg>

Exported directly from a design tool, this file often comes out at 350–400+ bytes before any cleanup. Here's where that goes:

1. XML comments.  and similar auto-generated comments are pure dead weight — they exist for the editor's internal bookkeeping, not for rendering, and browsers ignore them entirely at runtime while still paying the download cost.

2. Editor metadata and redundant namespaces. Design tools often emit extra namespace declarations (xmlns:xlink, editor-specific attributes) that aren't used anywhere in the actual markup — vestigial from the export process, not required by the SVG spec for this content.

3. Unnecessary IDs and grouping. id="Background" and id="AccentCircle" are meaningful to a human editing the file in a design tool, completely irrelevant to a browser rendering it, unless something in your code actually references those IDs (via CSS, JS, or <use>). If nothing does, they're pure overhead.

4. Whitespace and formatting. Indentation, line breaks, and spacing make the file readable for humans and add literally zero rendering value — this is the most "free" savings available, since it changes nothing about how the SVG looks or behaves.

5. Excessive path precision. Not visible in this example, but extremely common in path-heavy icons: coordinates like d="M12.000123 8.499987..." where 6+ decimal places of precision exist for a shape that renders identically at 2 decimal places, because that's just what the export tool defaulted to.

What Safe Minification Actually Removes

The key word is safe — some "optimizations" genuinely change rendering (color space conversion, aggressive path simplification that alters shape), and some are risk-free because they touch nothing a renderer uses:

Strip comments — zero risk, comments are never rendered
Remove unused XML headers and editor-specific metadata namespaces — zero risk if nothing references them
Minify whitespace (collapse indentation and line breaks) — zero risk, purely cosmetic in the source
Remove IDs only if nothing in your codebase references them — this one requires actually checking, not assuming

For the example above, comments + editor metadata + whitespace minification alone gets that file from ~375 bytes down to roughly 300 — an 18–20% reduction with zero visual risk, before even touching path precision or considering whether those IDs are actually used anywhere.

Where This Actually Matters

For a single icon, 75 bytes doesn't matter. It matters when:

You're inlining dozens of SVG icons directly in HTML/JSX (a common pattern for icon systems) — the savings compound across every instance
You're building an icon sprite sheet referenced across an entire app
SVGs are part of your critical rendering path (above-the-fold logos, hero graphics) where every KB affects Largest Contentful Paint

A Note on React/JSX Specifically

If you're inlining SVGs as React components, there's a second layer worth knowing about: SVG attribute names don't match JSX conventions directly — stroke-width needs to become strokeWidth, xlink:href needs handling as a namespaced prop, and self-closing tags need to actually be self-closed for JSX to parse them. A tool that exports both optimized SVG markup and a JSX-ready version saves that manual conversion step, which is easy to get wrong by hand on a complex path-heavy icon.

Try It

I added an SVG optimization tool to ResizeHub that runs this cleanup entirely client-side — paste or upload an SVG, toggle which minification rules to apply, and export either the cleaned markup or a JSX-ready version directly. No upload, processed in your browser.

What's the worst SVG bloat you've run into — design-tool exports, or something else entirely (icon font migrations, hand-written SVGs with copy-pasted boilerplate)?

The 50KB Problem: Why Government Forms Keep Rejecting Your Photo

Vijay Kanna — Sun, 26 Jul 2026 15:36:18 +0000

There's a deceptively simple bug hiding in plain sight on almost every government form, university portal, and job application site: "Upload a photo under 50KB." No API, no error message explaining why, no tolerance — just silent rejection if you're 2KB over.

It sounds like a trivial constraint until you actually try to satisfy it programmatically. File size in bytes isn't a variable you can set directly; it's a derived value — a function of pixel dimensions, image entropy, and compression quality — which makes "resize this to exactly 51,200 bytes" a surprisingly nontrivial optimization problem, not a one-line canvas.toBlob() call.

A few months ago, my cousin ran into this on a state exam portal that capped passport photos at 50KB. She spent two hours bouncing between random "photo compressor" sites, most of which just apply a fixed compression ratio and let you deal with whatever number comes out. None of them actually solve for a target size. By the time she landed on something that worked, the registration window had closed for the day.

So here's the actual technical problem underneath this UX annoyance — and how to solve it properly instead of guessing quality percentages by hand.

It's Not You. File Size Is Genuinely Unpredictable.

Here's the thing nobody tells you: file size in kilobytes isn't something you can just "set." It's the result of several things happening at once — how detailed the image is, what dimensions it's saved at, and how aggressively it's compressed. Change any one of those, and the final number shifts unpredictably.

A plain white background compresses down to almost nothing. A busy, detailed photo — a face with visible texture, a signature with lots of fine ink strokes — resists compression much harder, because there's more actual information in the pixels. Two photos that look similarly sized on your screen can land at wildly different file sizes once compressed, simply because of what's in them.

Then there's the format problem, which trips up almost everyone. If your image is a PNG (which is what a lot of screenshot tools and scanning apps default to), you're fighting an uphill battle. PNG is a lossless format — it never throws away any pixel detail, no matter how much you compress it. That's exactly why it's terrible for hitting a tiny KB target. JPEG, on the other hand, is built to selectively discard detail the human eye barely notices, which is precisely the kind of flexible compression you need to land on an exact number. This is also why almost every exam portal explicitly asks for a JPG, not a PNG — they know PNG can't reliably hit their limit.

The Numbers Aren't Random Either

Once you start looking at these limits across different portals, a pattern shows up:

20KB shows up almost exclusively for signature scans.
30KB is usually a thumb impression or biometric scan.
50KB is the classic passport-style photo limit — SSC, UPSC, IBPS, most competitive exams.
100KB covers ID document scans like Aadhaar cards, where legible text matters more than photographic detail.
150–200KB shows up for visa photos and certificate scans, which need sharper detail or more content per image.

None of these are arbitrary. They exist because these systems were built to handle enormous submission volumes — millions of applicants uploading files during a narrow registration window — and tiny file sizes keep the servers from falling over.

Knowing why the number exists doesn't make hitting it easier, though. That still comes down to process.

The Actual Fix: Work Backwards From the Number

Here's what finally worked for my cousin, and what I'd tell any dev building or using one of these tools: stop treating this as "apply compression and check the result." Treat it as a search problem. You have a target byte count, and a monotonic (roughly) relationship between JPEG quality and output size — so a binary search over quality levels, re-encoding via canvas on each iteration, converges on the right setting in a handful of steps instead of one lucky guess. If quality alone can't hit the target even at the low end, the next lever is scaling down pixel dimensions in small increments, not crushing quality further.

That's the approach behind a browser-based tool like ResizeHub's exact-KB image resizer — pick a preset (20KB, 50KB, 100KB, whatever the form asks for) or type a custom number, and it runs that iterative compress-check-adjust loop for you instead of you doing it by hand in Photoshop. If a PNG comes in, it converts to JPG automatically, since PNG's lossless encoding can't be tuned down to an arbitrary byte target the way JPEG can. And because the whole thing runs in-browser via the Canvas API — no server round-trip — a signature or ID scan never actually leaves the device, which matters more than people think when the file in question is a government ID.

A few things that make a real difference no matter which tool you use:

Crop first, compress second. If the form wants a small passport-style photo and you upload a full 12-megapixel original, the compression algorithm has to work much harder — and throw away far more detail — to hit the target. Get close to the required dimensions before you compress.

JPG over PNG, every time, when a KB limit is involved. This one rule alone solves half the frustration people run into.

Always preview before submitting. Especially with signatures, where a few compressed pixels can turn a legible signature into a smudge.

The Small Number That Actually Matters

It's a strange feature of modern bureaucracy that a random number like "50KB" can decide whether someone makes a deadline. But once you understand why that number exists and how file compression actually works, it stops being a mystery and becomes a five-minute task instead of a two-hour one.

My cousin re-registered the next cycle. Photo compressed correctly, uploaded on the first try, in about thirty seconds. Not a dramatic ending, but that's kind of the point — it shouldn't have taken two hours in the first place.

If you're stuck on a similarly oddly-specific file size requirement, I wrote a more detailed breakdown of target sizes and formats here — happy to answer questions in the comments if your form has a weird limit I haven't covered.

Build a Client-Side Image Compressor in 30 Minutes (No Backend Needed)

Vijay Kanna — Wed, 22 Jul 2026 05:08:41 +0000

Most image compression tutorials assume you're running something server-side — Sharp, ImageMagick, a Node backend. This one doesn't need any of that. We're going to build a working image compressor that runs entirely in the browser, using nothing but the Canvas API.

By the end, you'll have a single HTML file that takes an image, compresses it, and lets the user download the result — no server, no dependencies, no build step.

What We're Building

A simple page where a user can:

Upload an image
Adjust a quality slider
See the compressed file size update live
Download the compressed result ## Step 1: The HTML Skeleton

<!DOCTYPE html>
<html>
<head>
  <title>Image Compressor</title>
</head>
<body>
  <input type="file" id="fileInput" accept="image/*">
  <br><br>
  <label>Quality: <span id="qualityValue">80</span>%</label>
  <input type="range" id="qualitySlider" min="1" max="100" value="80">
  <br><br>
  <canvas id="canvas" style="max-width: 400px; display: none;"></canvas>
  <p id="sizeInfo"></p>
  <a id="downloadLink" style="display: none;">Download Compressed Image</a>

  <script src="compress.js"></script>
</body>
</html>

Nothing fancy — a file input, a quality slider, a canvas to do the actual work, and a download link that appears once we have a result.

Step 2: Loading the Image Into Canvas

Canvas can't compress a file directly — it works with pixels. So the first job is getting the uploaded image drawn onto a canvas:

const fileInput = document.getElementById('fileInput');
const canvas = document.getElementById('canvas');
const ctx = canvas.getContext('2d');
let currentImage = null;

fileInput.addEventListener('change', async (e) => {
  const file = e.target.files[0];
  if (!file) return;

  const bitmap = await createImageBitmap(file);
  currentImage = bitmap;

  canvas.width = bitmap.width;
  canvas.height = bitmap.height;
  ctx.drawImage(bitmap, 0, 0);
  canvas.style.display = 'block';

  compressAndPreview();
});

createImageBitmap is the modern way to decode an image file — it's faster than the older Image() + onload pattern and works well with async/await.

If you need to support older browsers that don't implement createImageBitmap, you can fall back to using an Image element with an onload handler:

function loadImageFallback(file) {
  return new Promise((resolve, reject) => {
    const img = new Image();
    img.onload = () => resolve(img);
    img.onerror = reject;
    img.src = URL.createObjectURL(file);
  });
}

Both approaches draw onto the canvas the same way afterward — ctx.drawImage(bitmap, 0, 0) works whether bitmap came from createImageBitmap or this fallback.

Step 3: Compressing With `toBlob`

This is the actual compression step. canvas.toBlob() takes a format and a quality value (0 to 1) and re-encodes the canvas content:

const qualitySlider = document.getElementById('qualitySlider');
const qualityValue = document.getElementById('qualityValue');
const sizeInfo = document.getElementById('sizeInfo');
const downloadLink = document.getElementById('downloadLink');

function compressAndPreview() {
  if (!currentImage) return;

  const quality = qualitySlider.value / 100;

  canvas.toBlob((blob) => {
    const sizeKB = (blob.size / 1024).toFixed(1);
    sizeInfo.textContent = `Compressed size: ${sizeKB} KB`;

    const url = URL.createObjectURL(blob);
    downloadLink.href = url;
    downloadLink.download = 'compressed.jpg';
    downloadLink.textContent = `Download (${sizeKB} KB)`;
    downloadLink.style.display = 'inline';
  }, 'image/jpeg', quality);
}

qualitySlider.addEventListener('input', () => {
  qualityValue.textContent = qualitySlider.value;
  compressAndPreview();
});

That's the entire core mechanism. Move the slider, toBlob re-encodes at the new quality, and the size updates live.

Step 4: A Small but Important Fix — Memory Cleanup

Every time compressAndPreview() runs, it creates a new object URL with URL.createObjectURL(). If you don't release the old one, you leak memory — this adds up fast if someone drags the slider around for a while:

let previousUrl = null;

function compressAndPreview() {
  if (!currentImage) return;

  const quality = qualitySlider.value / 100;

  canvas.toBlob((blob) => {
    if (previousUrl) URL.revokeObjectURL(previousUrl);

    const sizeKB = (blob.size / 1024).toFixed(1);
    sizeInfo.textContent = `Compressed size: ${sizeKB} KB`;

    const url = URL.createObjectURL(blob);
    previousUrl = url;
    downloadLink.href = url;
    downloadLink.download = 'compressed.jpg';
    downloadLink.textContent = `Download (${sizeKB} KB)`;
    downloadLink.style.display = 'inline';
  }, 'image/jpeg', quality);
}

Small detail, easy to miss, and exactly the kind of thing that turns into a real memory leak if this code ever ships in something long-running.

What This Doesn't Handle (On Purpose)

This tutorial deliberately stops at "quality slider compression" because that's enough to actually understand the mechanism. A few things it leaves out, if you want to take it further:

Target file size instead of quality — this needs a search loop around toBlob (binary search on quality, falling back to resizing dimensions when quality bottoms out) rather than a direct slider
PNG support — toBlob works for PNG too, but PNG is lossless, so "quality" doesn't apply the same way; you'd be resizing or reducing color depth instead
Large image performance — very large images (many megapixels) can make toBlob noticeably slow; moving this to a Web Worker keeps the UI responsive during compression ## Next Challenges

Once you've built this version, try extending it with:

Drag-and-drop uploads
Batch compression
WebP output
AVIF output
Exact target-size compression
EXIF orientation handling ## Try It Yourself

Paste both snippets into an HTML file and open it in a browser — no build tools, no npm install, nothing to configure. That's the whole appeal of doing this client-side: it's genuinely just HTML, CSS, and the Canvas API doing real work.

If you want to see a fuller version of this same idea — target-size compression, PDF tools, and 70+ other browser-based utilities built on the same no-backend approach — I've been building ResizeHub using exactly this pattern, extended a lot further.

Why Compressing an Image to Exactly 50KB Is Harder Than It Sounds

Vijay Kanna — Tue, 21 Jul 2026 02:59:21 +0000

Ever wondered why one image hits 50KB at 80% quality while another is still 200KB at 20%? The answer isn't your compression library — it's how JPEG compression actually works. If you've ever tried building an "exact target size" image compressor, you've probably discovered this is a surprisingly hard optimization problem, not the one-line canvas.toBlob(quality) call it looks like from the outside.

Here's what's actually happening under the hood, and why "just lower the quality until it's small enough" isn't as simple as it sounds.

Quality Percentage and File Size Aren't Linearly Related

JPEG's "quality" setting doesn't control file size directly — it controls the quantization table used during compression, which determines how aggressively high-frequency detail gets discarded. The relationship between quality and resulting file size depends entirely on the image content:

A smooth gradient (sky, solid background) compresses extremely well at high quality — very little high-frequency detail to discard in the first place
A busy, high-detail photo (foliage, fabric texture, crowd scene) can be 5–10x larger than a smooth image at the same quality setting

This means "quality 70" might produce a 15KB file for one image and a 180KB file for another. A tool that just applies a fixed quality value and calls it done will wildly miss a target size depending on what's actually in the photo.

The relationship isn't linear either — file size drops fast at first as quality decreases, then flattens out, because the most "compressible" redundancy gets squeezed out early and what's left resists compression much harder:

Quality	Typical size (busy photo)	Typical size (smooth image)
100	~2.1 MB	~180 KB
90	~1.3 MB	~90 KB
80	~900 KB	~55 KB
70	~650 KB	~40 KB
60	~520 KB	~32 KB
40	~380 KB	~22 KB

(Illustrative shape of the curve, not measured output — the point is the curve flattens, not the exact numbers, which depend entirely on your specific image.)

That flattening is exactly why a naive "keep lowering quality until it's small enough" loop can spin through a dozen iterations near the bottom of the range and barely move the needle — at which point the only lever left is dimensions, not quality.

Why You Can't Just Binary-Search Quality Alone

The naive fix is: binary search the quality parameter until the output lands near your target size. This mostly works, but it breaks down at the edges:

Some images can't hit low targets at any quality setting without dropping resolution too — a 4000x3000px photo at quality 1 can still be well over 50KB, because dimension, not just quality, drives the byte count once compression is already near its floor
JPEG quality below ~10-15 produces visible blocking artifacts that make the "successful" output useless even though it technically hit the target size
PNG doesn't have a quality slider at all — it's lossless, so "compress to 50KB" means either reducing color depth (palette reduction) or reducing dimensions, an entirely different algorithm path than JPEG

A compressor that only tunes quality will either fail outright on some images, or "succeed" by producing something visibly broken.

What Actually Works: A Multi-Variable Search

A more robust approach searches across multiple parameters together, not quality alone:

Quality (for lossy formats) — the first lever, cheapest to adjust
Dimensions — downscaling before compressing is often more effective than cranking quality down further, especially for images that will be displayed small anyway (a signature, a thumbnail, an exam photo)
Chroma subsampling — reducing color resolution while keeping luminance detail (4:2:0 vs 4:4:4) can meaningfully cut size with minimal visible impact for photographic content
Format — for some content, switching from PNG to JPG or WebP entirely changes what's achievable at a given size, which is worth checking before assuming a target is impossible

A binary search over quality alone, falling back to progressive downscaling when quality bottoms out before hitting the target, gets you close to the actual achievable minimum — without silently destroying the image or endlessly failing. The decision flow looks roughly like this:

 Original image
       │
       ▼
 Binary search quality (target ±5%)
       │
       ▼
 Target reached? ──yes──▶ Done
       │no
       ▼
 Quality bottomed out (~10-15)?
       │yes
       ▼
 Reduce dimensions, reset quality search
       │
       ▼
 Target reached? ──yes──▶ Done
       │no
       ▼
 Report achievable minimum (don't fake success)

The Case Where It's Genuinely Impossible

Some images cannot hit a small target size without visible quality loss, full stop — a detailed, high-resolution photo asked to compress to 20KB is going to look bad no matter what combination of parameters you try, because there's a hard information-theoretic floor below which you're discarding data the human eye will notice missing.

This is the part most tools get wrong: they either silently return a degraded image and call it a success, or they just fail with no explanation. The honest approach is to report the achievable minimum and let the user decide, rather than pretending the target was hit.

Example Results

(These reflect the kind of outcome this approach produces — verify against your own implementation's actual output before publishing, and only call it "measured" if you've genuinely run these exact images through your compressor.)

Image type	Resolution	Original	Target	Final	Iterations
Portrait photo	4000×3000	3.8 MB	50 KB	49.8 KB	6
Signature scan	900×300	180 KB	20 KB	20.1 KB	2
Screenshot with text	1920×1080	1.1 MB	50 KB	64 KB	Quality floor reached

The screenshot case is the interesting one — quality search bottomed out before reaching 50KB, because a text-heavy screenshot doesn't have the same high-frequency redundancy a photo does. Going lower would've meant visible artifacts around the text, so the honest answer here is "closest achievable without damage," not "target hit."

How Format Choice Changes What's Achievable

Before assuming a target is impossible, it's worth checking whether a different format gets you there:

JPEG — best general-purpose choice for photographic content; the format most compression tutorials assume by default
PNG — no quality slider at all; hitting a small target means reducing color depth (palette/indexed color) or dimensions, a completely different code path than JPEG's DCT-based approach
WebP — typically 25–35% smaller than JPEG at comparable visual quality for photographic content, and supports both lossy and lossless modes; can still lose to PNG for flat-color graphics or images with sharp text edges
AVIF — generally beats WebP on compression ratio for photographic content, sometimes significantly, but encoding is meaningfully slower — a real cost for client-side, in-browser compression where the user is waiting on the result, and browser support is less universal than WebP's

For a target-size compressor specifically, this means the "impossible without visible quality loss" conclusion is format-dependent — a target unreachable in PNG might be trivial in WebP for the same image.

Doing This in the Browser

If you're doing this client-side (Canvas API, no server round-trip), the mechanics are similar but with real constraints:

async function compressToTarget(file, targetKB, maxIterations = 8) {
  const img = await createImageBitmap(file);
  let quality = 0.8;
  let scale = 1.0;
  let low = 0.1, high = 1.0;

  for (let i = 0; i < maxIterations; i++) {
    const canvas = document.createElement('canvas');
    canvas.width = img.width * scale;
    canvas.height = img.height * scale;
    const ctx = canvas.getContext('2d');
    ctx.drawImage(img, 0, 0, canvas.width, canvas.height);

    const blob = await new Promise(resolve =>
      canvas.toBlob(resolve, 'image/jpeg', quality)
    );
    const sizeKB = blob.size / 1024;

    if (Math.abs(sizeKB - targetKB) < targetKB * 0.05) {
      return blob; // within 5% of target — good enough
    }

    if (sizeKB > targetKB) {
      high = quality;
      quality = (low + high) / 2;
    } else {
      low = quality;
      quality = (low + high) / 2;
    }

    // If quality search has bottomed out and we're still over target,
    // start reducing dimensions instead of pushing quality lower
    if (quality < 0.15 && sizeKB > targetKB) {
      scale *= 0.85;
      quality = 0.5;
      low = 0.1; high = 1.0;
    }
  }

  return null; // couldn't hit target without falling back to scale reduction
}

The interesting engineering problem isn't the binary search itself — it's deciding when to stop trusting quality reduction and switch to dimension reduction instead, and knowing when to give up and report the honest floor rather than returning something technically-compressed-but-visually-broken.

Why This Matters Beyond Just Images

The same shape of problem shows up anywhere you're targeting a byte budget instead of a quality parameter — video export for a size-limited platform, PDF compression for an email attachment cap, even audio encoding for a storage quota. The pattern is the same: single-variable search gets you most of the way, but the interesting failure modes live at the edges where the target genuinely isn't achievable without a second variable (dimensions, bitrate, sample rate) coming into play.

I ran into these edge cases while building ResizeHub, a browser-based image compression tool with exact target-size support. The engineering challenge turned out to be much more about search strategies than compression itself.
If you'd like to experiment with the algorithm,
try the live implementation on
ResizeHub.

9 Things Developers Confidently Say About "It Runs Entirely in the Browser"

Vijay Kanna — Sun, 19 Jul 2026 15:02:25 +0000

"Client-side" has become one of those phrases that gets said with total confidence and about 60% accuracy. Here are nine things I've heard — said some of them myself — that sound right until you actually test them.

"It's more private because it's client-side."
Sure, if nothing else on the page is calling out to a third-party script, an analytics pixel, or a CDN-hosted library that phones home. "Runs in the browser" and "sends nothing anywhere" are not the same claim, and a lot of client-side tools quietly do both without realizing it.
"No server means no cost."
No compute cost, sure. Still paying for hosting, bandwidth on every asset, and the CDN serving your now-much-larger JS bundle to every single visitor whether they use the feature or not.
"It'll work the same on mobile."
It will work. "The same" is doing a lot of heavy lifting in that sentence, especially the first time Canvas or Web Workers hits an actual memory ceiling on a five-year-old Android phone.
"We don't need a backend at all now."
Right up until you need auth, rate limiting, or literally anything that requires trusting the client not to lie to you — which, gentle reminder, you should never do.
"Client-side means it's automatically fast."
Client-side means it's fast if you're disciplined about what loads when. Ship every dependency on page load "because it's all client-side anyway" and you've just moved the slowness from a server response to a JS parse.
"SEO doesn't matter as much since it's an app, not a website."
Said by someone who has never tried to explain to a client why their beautifully engineered client-side app doesn't show up on page one of anything.
"The browser will just garbage collect it, it's fine."
It will, eventually, probably, unless you've built a closure that's quietly holding a reference to a 40MB canvas buffer that never gets released and now the tab crashes after the fourth image.
"Nobody actually inspects the network tab."
Somebody always inspects the network tab. Usually right when you claimed nothing gets uploaded.
"It's basically done once it works on my machine."
On your M-series MacBook, on fiber, on Chrome. The real test is a mid-range Android phone on 4G with twelve tabs already open — which is a huge share of real users and none of your local testing.

None of this is an argument against client-side architecture — I'm neck-deep in exactly this building a 70+ tool browser-based toolkit and would make the same trade-offs again. It's more that "it runs in the browser" gets said as if it settles an engineering debate on its own, and it really doesn't.

What's the one you've said out loud and had to walk back later? Or the one you still believe and think I'm wrong about — genuinely curious which of these gets argued with the most.

I Built a Tool That Resizes Images to an Exact KB Target Instead of a Quality Slider

Vijay Kanna — Sun, 19 Jul 2026 05:37:27 +0000

Every image resizer I tried had the same problem: you drag a "quality" slider and hope the output lands under whatever limit you actually need.

That's fine if you're optimizing a blog header. It's useless if a government exam portal tells you "signature must be under 20KB" and rejects your file three times before you land close enough by trial and error.

So I built a resizer that works backward from a target file size instead of a quality percentage. You type "50KB," it iterates compression internally until the output is as close as possible to that number, then gives you the file.

How it works, roughly:

Runs entirely in the browser (Canvas API + a binary search over quality/dimension steps)
No upload to a server, so it's fast and doesn't touch your original file
Converges on a target size within a few passes instead of guessing What surprised me building it: The hard part wasn't the compression — it was handling images that can't hit the target no matter how much quality you strip, without silently returning garbage. Had to add a floor where it tells you "can't go below X without destroying the image" instead of pretending it succeeded.

It's part of a small toolkit I've been building — ResizeHub — free, no login, no watermark. This particular tool came directly out of watching people in exam-prep forums complain about signature/photo size rejections.

Curious if others have hit the same "quality slider vs. target size" mismatch in other contexts — video export, PDF compression, etc. What's your workaround been?

Scaling a Single React App to 71+ Browser-Based Tools Without Killing Load Time

Vijay Kanna — Sat, 18 Jul 2026 12:20:07 +0000

The problem with "just add another tool"

When you're building one image tool, performance is easy. When you're building 71 of them in the same app — resize, compress, crop, PDF merge, format converters, exam-photo presets, social media templates — the naive approach (import everything, bundle it all together) turns your app into a multi-megabyte JavaScript payload before a user has even picked a tool.

This is the actual engineering problem behind ResizeHub, which now has 71+ tools across 11 categories, all running client-side with zero server uploads. Here's how the architecture holds up at that scale.

Stack, and why each piece earns its place

React + TypeScript — type safety matters more, not less, as tool count grows. A shared ImageProcessor interface that every tool implements catches integration bugs at compile time instead of in production.
Vite — its native ES modules dev server and Rollup-based production build made code-splitting dramatically easier to reason about than older bundlers, which matters a lot once you have dozens of independent tool routes.
HTML5 Canvas API — the actual compression/resize/crop engine, shared across tools rather than reimplemented per-tool.
Cropper.js — for interactive cropping UI specifically (aspect-ratio locking, circular crop for signatures) rather than rebuilding drag-handle math from scratch.
Pica — for high-quality image downscaling; the browser's native canvas scaling can introduce visible aliasing on large downscales, and Pica's algorithm handles this noticeably better.
Cloudflare Pages — static hosting with edge caching, which matters since 100% of the actual processing work happens in the user's browser, not on any server at all.

Lesson 1: Route-level code splitting isn't optional past a handful of tools

With React Router and dynamic import(), each tool becomes its own chunk:

const PhotoResizer = lazy(() => import('./tools/PhotoResizer'));
const PdfCompressor = lazy(() => import('./tools/PdfCompressor'));
const SignatureCropper = lazy(() => import('./tools/SignatureCropper'));

Without this, every visitor downloads the code for all 71 tools just to use one. With it, a user landing on the SSC photo tool only pulls that tool's bundle plus shared core — not the PDF merger, not the social media template generator, not tools they'll never touch in that session.

Lesson 2: Share the processing core, isolate the UI

The temptation with many similar tools is to copy-paste a working tool and tweak it. That works for the first five tools and becomes unmaintainable by tool thirty. The fix that held up: a shared core engine (resize, compress-to-target-KB, format conversion, crop math) that every tool imports, with only the UI and preset configuration differing per tool.

// shared core
export function resizeToTarget(canvas: HTMLCanvasElement, spec: ToolSpec) { ... }

// per-tool, just config
const sscPhotoSpec: ToolSpec = {
  width: 200, height: 230, maxKB: 20, format: 'jpeg', background: 'light'
};
const ibpsPhotoSpec: ToolSpec = {
  width: 200, height: 230, maxKB: 50, format: 'jpeg', background: 'light'
};

This means adding tool #72 for a new exam board is a config object, not new processing logic — and a bug fix in the core engine fixes it everywhere at once instead of needing to be copy-pasted across dozens of files.

Lesson 3: Category-level grouping helps both users and bundlers

Organizing 71 tools into 11 categories (Resize, Compress, Convert, Crop & Edit, PDF, Exam Tools, Social Media, Enhancement, Utility, Batch, Privacy) wasn't just a UX decision — it maps naturally onto chunk boundaries too. Tools within a category often share more code (e.g., all exam-photo tools share background-validation logic) than tools across categories, so grouping by category keeps related code physically close and shared chunks smaller and more targeted.

Lesson 4: Batch processing needs a different execution model

Single-image tools can process synchronously without the user noticing. Batch tools (batch resize, batch compress, batch convert across many files) need to avoid blocking the main thread, or the UI freezes on a 50-image batch. The practical fix is chunked async processing with requestIdleCallback or a Web Worker for the heavier operations, processing a few images at a time and yielding back to the browser between chunks so the UI stays responsive and progress can actually update.

Lesson 5: Type-safe tool specs prevent an entire category of bugs

With 71 tools, many sharing similar-but-not-identical specs (every government exam board has slightly different photo requirements), a loosely-typed config object is a bug magnet. A strict ToolSpec interface, checked at compile time, catches "someone typo'd the KB limit for one exam board" before it ships rather than after a user's application gets rejected because of it — which matters more here than in most apps, since a wrong spec has a real downstream cost for someone filling out a government form.

What this adds up to

None of these are exotic techniques individually — code splitting, shared core logic, typed configs are all fairly standard React practice. The interesting part is that at 5-10 tools, skipping all of this barely matters. At 70+, skipping any one of them compounds into real load-time and maintainability problems. The architecture decisions that don't matter early are exactly the ones that determine whether scaling to "one more tool" stays cheap or becomes expensive.

If you're curious how this plays out in practice, the live result — 71+ tools, all client-side, no uploads — is at resizehub.in.

Curious from others in the comments

If you've built a similar "many small tools, one app" product, I'd like to compare notes — specifically on whether you went with route-based splitting like this or a micro-frontend approach instead, and where that tradeoff started to matter for you.

I Built a Free Image Resizer That Never Uploads Your Photos to a Server — Here's How

Vijay Kanna — Sat, 18 Jul 2026 00:51:55 +0000

The problem I kept running into

Every time I needed to resize a photo for a passport application, an exam form, or just to shrink a screenshot before sharing it, I ended up on some random "free" image tool that:

Uploaded my photo to their server (privacy, anyone?)
Buried the download button under three ad banners
Forced me to sign up for a "free" account
Randomly failed on files over 2MB

So I built ResizeHub — a completely free, browser-based image toolkit that resizes, compresses, and converts images without ever sending your file to a server. Everything happens client-side, in your browser, using the Canvas API.

Here's a breakdown of how it works and why client-side image processing is a genuinely underrated approach for web tools.

Why process images in the browser instead of on a server?

Most "free" image tools follow the same pattern: user uploads file → server processes it → server sends back a result. That's simple to build, but it comes with real costs:

Privacy risk — your image (which might contain a face, ID document, or signature) sits on someone else's server, even if briefly
Server cost — every resize operation burns compute and bandwidth on the backend, which is why most of these tools carry ads or paywalls
Latency — upload time + processing time + download time, especially painful on slow connections
Scalability ceiling — more users means more server load, so free tiers get throttled fast

Doing it client-side flips all of this:

const canvas = document.createElement('canvas');
const ctx = canvas.getContext('2d');
const img = new Image();

img.onload = () => {
  canvas.width = targetWidth;
  canvas.height = targetHeight;
  ctx.drawImage(img, 0, 0, targetWidth, targetHeight);

  canvas.toBlob((blob) => {
    // blob is your resized image — ready to download
    // it never left the browser
  }, 'image/jpeg', quality);
};

img.src = URL.createObjectURL(userFile);

That's genuinely most of the core logic. The Canvas API gives you pixel-level control over dimensions, and toBlob() lets you control output quality and format entirely on the client.

Handling exact file-size targets (the hard part)

Resizing to exact dimensions is easy. Resizing to an exact file size (a common requirement for government exam forms — "signature must be under 20KB") is trickier, because JPEG compression quality doesn't map linearly to output size.

The approach that works well is a binary search over the quality parameter:

async function compressToTargetSize(canvas, targetKB, mimeType = 'image/jpeg') {
  let min = 0, max = 1, quality = 0.7;
  let result;

  for (let i = 0; i < 8; i++) {
    result = await new Promise((resolve) =>
      canvas.toBlob(resolve, mimeType, quality)
    );

    const sizeKB = result.size / 1024;

    if (Math.abs(sizeKB - targetKB) < 2) break;

    if (sizeKB > targetKB) {
      max = quality;
    } else {
      min = quality;
    }
    quality = (min + max) / 2;
  }

  return result;
}

Eight iterations of binary search converge close enough for practical purposes, and it all runs in milliseconds since there's no network round trip.

Format conversion without a backend

Converting between formats (PNG ↔ JPEG ↔ WebP) is just a matter of changing the MIME type passed to toBlob() — the browser's built-in codecs handle the actual encoding. No image-processing library, no server, no dependency bloat.

For formats the Canvas API doesn't natively support (like HEIC, common on iPhone photos), a lightweight WASM decoder can convert to a canvas-compatible format first, still entirely client-side.

What this approach is good and bad for

Good for: resizing, compressing, cropping, format conversion, basic adjustments — anything the Canvas API can express as pixel operations.

Not great for: heavy AI operations like background removal or upscaling, which genuinely need a model running somewhere. Those still need a server (or an on-device ML model, which is a whole separate rabbit hole).

Try it

I packaged this into a free toolkit at resizehub.in — includes image resize/compress, exact-KB compression for exam forms, passport/signature photo presets, and format conversion. No signup, no upload limits since nothing uploads in the first place.

If you're building something similar or have ideas for improving the compression algorithm, I'd genuinely like to hear about it in the comments.

15 Free Browser-Based Image Tools Every Student Should Bookmark published

Vijay Kanna — Thu, 09 Jul 2026 03:52:40 +0000

Whether you're submitting a university assignment, applying for internships, or filling out government exam applications, image editing is something most students eventually need.

The problem? Many people still install large desktop applications just to resize a photo or convert a PNG into JPG.

Modern browser-based tools can do these tasks in seconds without requiring installation. Here are 15 that are genuinely useful.

1. Passport Photo Resizer

Perfect for exam applications that require strict dimensions and file-size limits.

Useful for:

Government exams
Visa applications
College admissions

2. Signature Resizer

Many online portals reject signatures because they're just a few KB too large.

A signature resizer helps:

Reduce file size
Preserve sharpness
Export in the required format

3. Image Compressor

Compress images while maintaining visual quality.

Ideal for:

Email attachments
Assignment uploads
Portfolio websites

4. Bulk Image Compressor

Need to optimize dozens of images? Batch compression saves a surprising amount of time compared to doing them one by one.

5. Crop Tool

Crop passport photos, scanned documents, screenshots, or profile pictures with precise control.

6. PNG → JPG Converter

Some websites only accept JPG uploads. A quick format conversion solves the problem instantly.

7. JPG → PNG Converter

Useful when working with logos, graphics, or images that require transparency.

8. WEBP → JPG Converter

Many images downloaded from the web are now in WEBP format by default. Converting them to JPG improves compatibility with older systems and forms.

9. HEIC → JPG Converter

If you use an iPhone, you've probably encountered HEIC images that won't upload everywhere. This fixes that in one step.

10. AVIF Converter

Convert modern AVIF images into formats supported by older applications and portals.

11. SVG Optimizer

Developers can strip unnecessary SVG metadata and reduce file size without changing appearance — handy for keeping repos and websites lean.

12. Instagram Image Resizer

Generate correctly sized images for:

Feed
Stories
Reels

13. YouTube Thumbnail Resizer

Prepare thumbnails using recommended dimensions before uploading videos.

14. Social Media Image Resizer

Resize images for LinkedIn, Facebook, X (Twitter), Pinterest, and WhatsApp.

15. Universal Image Converter

Convert between common formats including:

JPG
PNG
WEBP
GIF
BMP
AVIF
HEIC

Why Browser-Based Tools Are Becoming More Popular

They offer several advantages over traditional desktop software:

No installation
Works on Windows, macOS, Linux, Android and iPhone
Fast processing
Beginner friendly
Accessible from anywhere

For simple image tasks, they're often all you need.

One Toolkit Instead of Multiple Websites

While writing this article, I realized I was constantly switching between different websites depending on the task.

That's one reason I built ResizeHub, a browser-based collection of image utilities including:

Passport Photo Resizer
Signature Resizer
Image Compressor
PNG ↔ JPG Converter
HEIC Converter
Crop Tool
SVG Optimizer
Bulk Image Compressor

Everything runs directly in the browser without requiring installation.

👉 https://resizehub.in

I'd also love to hear which browser-based image tools you use most often — drop them in the comments.

7 Free Online Image Tools Every Student and Job Seeker Should Bookmark

Vijay Kanna — Wed, 08 Jul 2026 03:11:23 +0000

If you've ever applied for a government exam, a university program, or a job online, you already know the pain: "Photo must be under 50KB, dimensions 200x230px, JPG format only."

One rejected upload because your signature file is "too large" or your photo is "the wrong format" can cost you a completed application. The good news — you don't need Photoshop or any downloaded software to fix this. A handful of free, browser-based image tools can handle it in seconds, directly from your phone or laptop.

Here are seven tools worth bookmarking, especially if you're prepping documents for SSC, IBPS, SBI, RRB, UPSC, NEET, or university admission portals.

Tool	Best For
Passport Photo Resizer	Government exam applications
Signature Resizer	Exam & job application signatures
Image Compressor	Reduce image file size
PNG to JPG	Format conversion
JPG to PNG	Transparent graphics
Crop Tool	Trim unwanted areas
Bulk Image Compressor	Multiple images at once

1. Passport Photo Resizer — Fix Dimensions and File Size Instantly

Government exam portals are notoriously strict about photo specs. A dedicated passport photo resizer lets you set:

Exact width and height (in px, cm, or inches)
Target file size (KB/MB)
Output format (JPG/PNG)
Live preview before download

Instead of guessing settings in an image editor, you get exam-ready output in one pass.

2. Signature Resizer — Meet Strict Upload Requirements

Digital signature requirements are often stricter than photo requirements — many forms reject a signature scan simply because it's a few KB too large. A signature resizer should let you:

Resize to the exact pixel dimensions requested
Keep the signature crisp and legible after compression
Shrink file size without visible quality loss
Export instantly in the required format

This one small step is where a lot of applications get stuck.

3. Image Compressor — Shrink File Size, Keep Quality

Large images slow down uploads and often exceed portal limits outright. A browser-based image compressor helps by:

Reducing file size significantly
Preserving visual quality
Speeding up form submissions
Saving device storage

Handy well beyond exams too — resumes, portfolios, and personal websites all benefit from lighter image files.

4. PNG to JPG Converter — Fix Format Compatibility Issues

Not every portal accepts every format. A PNG to JPG converter lets you:

Cut file size (PNGs are often much larger than JPGs)
Match the format a portal actually accepts
Convert in seconds, no software required

5. JPG to PNG Converter — When You Need Transparency

Sometimes it's the opposite problem — you need a transparent background for a logo, presentation graphic, or design mockup. A JPG to PNG converter covers that use case cleanly.

6. Crop Tool — Isolate Exactly What's Needed

Many forms want just a face, just a signature, or just one section of a scanned document. A simple online crop tool helps you:

Remove unwanted background or margins
Isolate the required content precisely
Produce a cleaner, application-ready file

7. Bulk Image Compressor — Handle Multiple Files at Once

If you're compressing photos one at a time, you're wasting time. A bulk image compressor lets you:

Process several images in a single batch
Download everything as one archive
Keep every file within size limits

Especially useful for photographers, content creators, and anyone submitting multiple documents at once (mark sheets, ID proofs, certificates, etc.).

Why Browser-Based Image Tools Beat Desktop Software

Zero installation — works the moment you open the tab
Cross-platform — Windows, macOS, Linux, Android, iPhone, all the same
Fast — most edits process in under a second
Privacy-friendly — many tools process images locally, so files never leave your device
Beginner-friendly — no editing skills required

Where to Find All of These in One Place

Rather than bouncing between five different sites, I've been using ResizeHub — it bundles the Passport Photo Resizer, Signature Resizer, Image Compressor, PNG↔JPG converters, Crop Tool, and Bulk Image Compressor into a single browser-based toolkit. No sign-up, no installs — you just open ResizeHub and pick the tool you need.

Frequently Asked Questions

What is the best free tool to resize a passport photo online?
A browser-based passport photo resizer that lets you set exact width, height, and target file size (in KB) — like the one on ResizeHub — is the fastest way to meet exam or visa photo specifications without installing software.

How do I reduce my signature file size for exam applications?
Use a signature resizer that compresses the image while keeping the strokes legible, and lets you export directly to the KB limit the form specifies.

Can I compress multiple images at once for free?
Yes — bulk image compressors let you upload several files together and download them all compressed in one batch, which saves significant time over compressing images individually.

Is it safe to use online image tools for personal documents like signatures or ID photos?
Look for tools that process images locally in your browser rather than uploading them to a server. This keeps sensitive documents like signatures and ID photos on your own device.

Final Thoughts

Whether you're applying for a government job, submitting university documents, or just prepping images for a resume or portfolio, having a reliable browser-based toolkit saves real time. Bookmark one, and you'll never scramble over a "file size exceeds limit" error again.

The best tools are the ones you don't have to think about. When resizing images takes just a few clicks, you can spend your time on what actually matters — completing your application, not fixing file errors.

How to Resize Passport Photos & Signatures for Government Exam Applications

Vijay Kanna — Tue, 07 Jul 2026 06:41:28 +0000

If you're applying for government jobs, banking exams, railway recruitment, university admissions, or competitive exams like SSC, SBI, UPSC, RRB, or IBPS, you've probably encountered strict image upload requirements.

Most application portals require passport photos and signatures to meet specific file size, dimensions, and format requirements. Preparing these files correctly before uploading can save time and help avoid application rejections.

** Why Image Resizing Matters**

Many online application portals reject uploaded images because:

The file size exceeds the allowed limit.
The image dimensions don't match the required specifications.
The file format isn't supported.
Compression reduces image quality too much.

Instead of repeatedly uploading and getting errors, it's easier to prepare the image correctly beforehand.

Resize Images in Your Browser

I built ResizeHub.in to help users resize and compress images directly in the browser while keeping their files private. It supports popular image formats, including JPG, PNG, WEBP, AVIF, and HEIC, making it useful for both exam applications and everyday image optimization.

** How to Resize Your Photo or Signature**

The process is simple:

Upload your passport photo or signature.
Select the required dimensions or file size.
Preview the result before downloading.
Download the optimized image.
Upload the image to your application portal.

This usually takes less than a minute.

Which Image Format Should You Use?

| Format | Best For |

Choosing the right format can help maintain image quality while meeting upload requirements.

Why Privacy Matters

Government applications often require personal documents such as passport photographs and signatures. Using tools that process images directly in your browser can help reduce the need to upload these files to external servers.

Final Thoughts

Preparing your images correctly before submitting an application can save time and reduce the chances of upload errors.

If you're looking for a browser-based image tool that helps resize, compress, crop, and convert images while keeping your files on your device, you can try ResizeHub at https://resizehub.in.