DEV Community: Ubed Sheikh

Why WebP to JPG Conversion Breaks on Most Tools — And How the HTML5 Canvas API Fixes It

Ubed Sheikh — Thu, 04 Jun 2026 17:31:20 +0000

If you've ever downloaded an image from WhatsApp, a website, or an Android screenshot and tried to upload it to a government portal or older app — only to get a "format not supported" error — you've hit the WebP problem.

This post explains why it happens, what most tools get wrong, and how browser-based conversion using the HTML5 Canvas API actually solves it cleanly.

Why WebP Breaks on So Many Platforms

WebP was developed by Google in 2010 and is now the default format for images on Chrome, Android, and most modern websites. It produces files 25–35% smaller than JPG at the same visual quality.

The problem: a huge number of platforms still don't support it.

Indian government portals (Aadhaar, SSC, UPSC, Railway) — require JPG only
WhatsApp Web downloads — saves as .webp by default
Older Windows apps — don't open WebP natively
Email attachments — many clients can't render WebP
Job portals like Naukri — require JPG profile photo

So you have a perfectly good image, in a modern format, that half the world can't use.

What Most Online Converters Get Wrong

Most online image converters are server-side. You upload your file → it goes to their server → gets converted → you download the result.

Three problems with this:

1. Privacy risk. Your Aadhaar photo, passport scan, or ID document just got uploaded to a random server you know nothing about.

2. Quality loss from double compression.
Server-side tools often re-compress the image twice — once on upload, once on conversion. You lose quality you didn't need to lose.

3. They break on edge cases. Animated WebP,
WebP with transparency, or WebP files above a certain size often fail silently on server-side tools.

The Browser-Based Approach: HTML5 Canvas API

Modern browsers can handle image conversion entirely client-side using the Canvas API. No server needed.

Here's the core of how it works:

function convertImage(file, targetFormat, quality) {
  return new Promise((resolve) => {
    const img = new Image();
    const url = URL.createObjectURL(file);

    img.onload = () => {
      const canvas = document.createElement('canvas');
      canvas.width = img.naturalWidth;
      canvas.height = img.naturalHeight;

      const ctx = canvas.getContext('2d');

      // For JPG output: fill transparent areas with white
      // (JPG doesn't support transparency)
      if (targetFormat === 'image/jpeg') {
        ctx.fillStyle = '#FFFFFF';
        ctx.fillRect(0, 0, canvas.width, canvas.height);
      }

      ctx.drawImage(img, 0, 0);

      canvas.toBlob((blob) => {
        URL.revokeObjectURL(url);
        resolve(blob);
      }, targetFormat, quality);
    };

    img.src = url;
  });
}

The key method is canvas.toBlob(). It accepts:

type — the target MIME type (image/jpeg, image/png, image/webp)
quality — a value between 0 and 1 for lossy formats like JPG and WebP

The browser handles all the encoding natively.
Your file never leaves the device.

The Gotcha: Transparency in JPG Output

One thing that catches a lot of developers: JPG doesn't support transparency.

If you're converting a PNG or WebP with a transparent background to JPG, you need to explicitly fill the canvas with white (or whatever background colour you want) before drawing the image — otherwise you get black
or corrupted areas.

That's what this line does in the snippet above:

if (targetFormat === 'image/jpeg') {
  ctx.fillStyle = '#FFFFFF';
  ctx.fillRect(0, 0, canvas.width, canvas.height);
}

Most broken converters skip this step.

Real-World Use Case: India's Government Portals

This is the gap I ran into personally. In India, almost every government portal — Aadhaar, SSC CGL, UPSC, Railway RRB, passport applications —
requires photos in JPG format, typically under 50KB.

But WhatsApp (used by ~500 million Indians) saves all images as WebP. Android screenshots are WebP. Most modern phone cameras offer WebP.

So you have a generation of users with WebP files on their phones who can't upload them to the portals they need.

I built this conversion logic into EasyToolkit's free image converter — it handles WebP → JPG, PNG → JPG, and 6 other format combinations, entirely in the browser, with batch support for up to 20 files.

The India-specific angle (Aadhaar, SSC, UPSC portal requirements) is baked into the tool — it's genuinely the most common reason Indian
users need format conversion.

What I Learned Building This

A few things that weren't obvious before I built it:

TIFF files are complicated. The Canvas API doesn't natively decode TIFF. You need a library like UTIF.js for TIFF input support.

GIF animation doesn't survive conversion.
canvas.toBlob() captures a single frame. If someone converts an animated GIF to WebP expecting animation, they get a still image.
Worth flagging to users upfront.

Quality slider UX matters more than you'd think.
Users don't understand what "quality: 0.85" means. Showing the estimated output file size as they drag the slider is far more useful than a
percentage value.

Mobile performance is fine for single images, gets slow for batch. Converting 20 x 4MB images on a mid-range Android phone in sequence takes
longer than expected. Queuing conversions with a small delay between each one prevents the UI from freezing.

Summary

WebP is everywhere, but supported by almost no legacy platforms
Server-side conversion has real privacy and quality tradeoffs
canvas.toBlob() is the clean client-side fix - Fill transparent backgrounds before JPG output or you'll get black areas
For India specifically: WhatsApp → WebP → government portal rejection is a daily problem for millions of users

If you're building anything that touches image uploads in India, handling WebP → JPG conversion client-side is worth adding.

Built the image converter as part of EasyToolkit — a free browser-based toolkit for PDF, image,
and document utilities. All processing happens locally. Feedback welcome.

I was manually comparing two versions of a contract for 2 hours before I built this tool

Ubed Sheikh — Sun, 24 May 2026 09:16:23 +0000

A few months ago I was helping a friend review a revised freelance contract.

The client had "made a few small changes" - their words.

We had two PDF versions. No track changes. No diff. Just two documents that looked almost identical.

So we did what anyone does in that situation: opened both side by side and started reading. Line by line. Paragraph by paragraph.

Two hours later we found three changes. One of them was a payment clause that had been quietly reworded to cap late fees.

That experience stuck with me. Not because it was dramatic — but because it was completely avoidable.

The tools that exist weren't solving my actual problem

I knew diff checkers existed. I'd used them before for code.

But when I went looking for something that could handle:

Long-form text documents (not just code)
File uploads (not just paste)
URL comparison (compare two web pages directly)
Something that didn't upload my content to a server

I kept running into the same problems:

Most tools are built for developers comparing code, not people comparing documents
The ones that accepted files often uploaded them to external servers — not ideal for contracts or sensitive content
URL comparison either didn't exist or was buried behind a signup wall
The similarity score (how similar are these two texts, as a percentage?) was almost never shown

So I built my own.

What I focused on while building it

Browser-only processing. Everything runs in JavaScript inside your browser. No file ever touches a server. For contracts, legal documents, HR content — this matters.

Three comparison modes in one tool:

Paste text directly (Content A vs Content B)
Upload two files — TXT, CSV, JSON, HTML, MD, LOG
Paste two URLs and compare the live page content directly

Word-level diff, not just line-level. Most diff tools highlight entire changed lines. Word-level highlighting shows you exactly which word changed inside a sentence — much more useful for documents.

Similarity score. A percentage that tells you at a glance how similar two texts are. Useful when you need a quick sanity check before diving into the details.

Inline and side-by-side views. Some people prefer reading changes in flow. Others prefer the two-column comparison. Both are there.

One thing I didn't expect

URL comparison sounds simple. Fetch two pages, strip the HTML, compare the text.

It's not simple.

Cross-origin requests get blocked by a lot of websites. Some pages load content dynamically via JavaScript, which means a basic fetch only gets the shell. Others serve different content based on location, device, or login state.

I ended up building a best-effort URL comparison — it works well for most public pages, but I document the limitation clearly: if a site blocks cross-origin requests, text paste is the fallback.

Honest tools tell you what they can't do.

Who actually uses this (from real feedback)

I built it for my own problem, but the use cases that came back surprised me:

Writers comparing drafts before sending to editors
HR teams checking policy document versions
Developers comparing API response outputs during debugging
Students checking if two sources are too similar before submission
Anyone dealing with government or exam portals that return "updated" documents with no change log

That last one is very common in India specifically. Government portals update forms silently. You download a form, fill it out, then find out the portal has a newer version with different fields. A diff checker would have caught it in 10 seconds.

What I'm still working on

Better handling of tables inside documents (HTML table comparison is messy)
Export diff as PDF or HTML report
Bulk comparison across more than two files

If you've run into a specific comparison problem that existing tools don't handle well — I'd genuinely like to hear it in the comments.

Try it

If this sounds useful: Content Difference Checker

No signup. No file upload. Works in your browser.

What's the most frustrating "these two documents look the same but aren't" situation you've dealt with?

I'm asking because half of my feature ideas come from people describing problems I hadn't thought of. The contract story above came from a friend. The government form problem came from a comment on my last post. Curious what else is out there.

I built an image compressor that targets an exact KB size because upload portals kept rejecting my files

Ubed Sheikh — Sun, 17 May 2026 12:26:53 +0000

A few months ago I kept running into the same frustrating problem:

Upload portals rejecting my images because the file size was just slightly over the limit.

Especially on: It was frustrating re-compressing the same image over and over just to reduce a few extra KB.

Government forms
Exam portals
Visa applications
Job applications

Most image compressors either:

Reduced quality too aggressively
Failed to hit the required KB size
Uploaded files to external servers
Or required too many manual adjustments

So I ended up building a browser-based image compression tool focused on one specific thing:

Compressing images to an exact KB target while keeping the quality as usable as possible.

A few things I focused on while building it:

Browser-based processing
No signup
Adjustable KB targeting
Support for JPG, PNG, and WebP
Keeping the workflow simple

One thing I didn’t expect during development was how difficult ultra-low KB targets become.

For example:

Compressing a 2MB image to 500KB is easy
Compressing that same image to 20KB without destroying it is much harder

I also realized metadata removal can make a surprisingly big difference for photos taken on modern phones.

The project is still improving, but it has already become one of the tools I personally use most often.

I’m still improving it, but it has already become genuinely useful for handling strict upload limits:

https://easytoolkit.in/compress-image-to-kb/