DEV Community: dailytech.id

canvas.toBlob() Can Silently Hand You Back a PNG When It Can't Encode What You Asked For

dailytech.id — Tue, 28 Jul 2026 01:19:23 +0000

I was building a small in-browser image converter — drop in a PNG or JPEG, get back a WebP or AVIF, no server involved — and ran into a failure mode that doesn't look like a failure at all. The conversion "succeeds." The download works. The file just isn't the format you asked for, and unless you check for it, you'll never know.

The shape of the problem

The whole point of doing this client-side is that the image never leaves the browser. No upload, no server round trip, no queue. The pipeline is short:

const loadBitmap = async (file: File) => {
  if ('createImageBitmap' in window) return createImageBitmap(file);
  return new Promise<HTMLImageElement>((resolve, reject) => {
    const image = new Image();
    image.onload = () => resolve(image);
    image.onerror = reject;
    image.src = URL.createObjectURL(file);
  });
};

createImageBitmap(file) is the fast path — it decodes the file off the main thread without you needing to wire up an <img> element first. Not every environment has it, though, so there's a fallback to the classic new Image() plus URL.createObjectURL, which works everywhere but ties up the main thread during decode.

Once you have a bitmap, you draw it into a canvas — optionally downscaled — and ask the canvas for a blob in the target format:

const canvas = document.createElement('canvas');
canvas.width = width;
canvas.height = height;
const context = canvas.getContext('2d');
context.drawImage(bitmap, 0, 0, width, height);
if ('close' in bitmap && typeof bitmap.close === 'function') bitmap.close();

const mimeType = `image/${targetFormat}`;
const blob = await new Promise<Blob | null>((resolve) =>
  canvas.toBlob(resolve, mimeType, quality)
);

Calling bitmap.close() matters more than it looks — ImageBitmap objects hold decoded pixel data, and if you're running this over a batch of files, forgetting to release each one adds up fast in a single tab.

That code above is basically the whole feature. It's short enough that it's tempting to ship it as-is. Don't.

Where it quietly goes wrong

canvas.toBlob(callback, mimeType, quality) does not throw or reject when it can't produce the format you asked for. If the browser doesn't support encoding to that mimeType, it just falls back to PNG and calls your callback like nothing happened. No exception, no rejected promise, nothing in the console. This isn't a browser bug either — it's the specified behaviour, spelled out in MDN's toBlob() reference: an unsupported type falls back to image/png. The blob you get back is a real, valid, decodable image — it's just not the one you requested.

For a converter whose entire premise is "give me a smaller file in a modern format," this is close to the worst possible failure mode. AVIF and WebP exist specifically to be smaller than PNG for photographic content. If the encode silently downgrades to PNG, the user downloads a file that's often larger than what they started with, believing they got the compression they asked for. There's no error to catch, because nothing threw.

The only signal you have is the blob itself:

if (!blob || (blob.type && blob.type !== mimeType)) throw new Error('unsupported');

That one line is doing the actual work of catching the failure. It compares the type the browser reports on the resulting blob against the mimeType you requested. If they don't match, that's the silent-PNG-fallback case, and only then do we turn it into a real Error the rest of the app can react to — surfaced in the UI as an explicit "your browser couldn't encode this format" message instead of a mysteriously oversized download.

Encode support for something like AVIF isn't uniform across browsers and platforms the way JPEG decoding is — it depends on the underlying codec libraries a given browser ships with. Rather than trying to maintain a browser/version support matrix and hope it stays accurate, checking blob.type after the fact is the one method that's actually correct by construction: it asks the browser what it did, instead of guessing what it should be able to do.

The rest of the machinery

A few other details worth knowing if you're building something similar:

Downscaling is optional and cheap. A maxWidth setting only kicks in if it's set and the source is actually wider than it; otherwise the canvas is sized to the original dimensions and nothing is resized. It's a plain ratio calculation before drawImage, not a separate resize pass.

Quality defaults differ per format — 0.82 for WebP, 0.72 for AVIF. The quality argument is just a number between 0 and 1 handed to whichever encoder the browser uses, and the two codecs don't treat the same number the same way, so a single shared default doesn't make much sense. Whatever you pick, pick it per format.

Accepted inputs and batch size are both bounded. The converter accepts PNG, JPEG, GIF, WebP, and AVIF as input, and caps a batch at 50 files. That's a deliberate ceiling, not a technical one — decoding and holding dozens of full-resolution bitmaps in memory at once is exactly the kind of thing that degrades gracefully until it very suddenly doesn't.

Object URLs get cleaned up. Every file gets a URL.createObjectURL() preview, and every converted result gets another one for the download link. Both get explicitly revoked when a batch is cleared or re-converted. Blob URLs aren't garbage collected just because nothing references them anymore in your JS — leave enough of them alive in a long session and you'll leak memory for no visible reason.

What this approach doesn't give you

Worth being upfront about the tradeoffs of doing this in a canvas rather than server-side:

EXIF and orientation metadata are gone. drawImage followed by toBlob rasterizes pixels onto a canvas and re-encodes from there — none of the original file's metadata survives that trip. If you need to preserve camera info, GPS tags, or orientation flags, canvas-based conversion isn't the tool for it.
Everything lives in the tab's memory. There's no streaming, no chunking — the whole bitmap gets decoded and drawn in memory. A handful of large source images can push a browser tab further than you'd expect, especially on lower-memory devices.
Encode support isn't guaranteed, which is the whole reason the blob.type check exists in the first place, rather than being an edge case you can ignore.

None of this makes client-side conversion a bad idea — it's exactly why doing the work in the browser is appealing: no server storage, no upload wait, and the failure mode above is fully fixable in one line once you know to look for it. I ended up wrapping this into a small image-to-WebP tool I maintain, and if you're deciding between AVIF and WebP as your target format, I wrote up the actual tradeoffs in more detail here.

If you're building anything with canvas.toBlob(), the takeaway is narrow but worth remembering: a successful callback is not proof you got the format you asked for. Check blob.type.

iPhone Suddenly Stuck on SOS Only? This Simple Fix Saves Your Signal

dailytech.id — Fri, 02 Jan 2026 15:16:41 +0000

We’ve all been there: you pull out your iPhone to check a commit or a notification, and instead of 5G or LTE, the status bar displays "SOS Only." It’s a frustrating experience that usually happens at the worst possible time—after an iOS update, during travel, or randomly in the middle of your day.

But what does this state actually signify? Technically, "SOS Only" means your iPhone's modem cannot establish a handshake with your specific carrier (Verizon, T-Mobile, etc.), but it is detecting a signal from other nearby towers. Under international emergency standards, your phone is allowed to route emergency calls (911/112) through any available network, even if you aren't a subscriber.

If you’re stuck in this loop, here is the technical 8-step hierarchy to resolve the issue.

1. The Airplane Mode "Soft Reset"

The fastest way to force a re-scan of local frequencies is the Airplane Mode toggle. This forces the radio power amplifier to cycle off and on, clearing the current state of the cellular stack.

Open Control Center > Toggle Airplane Mode ON.
Wait 15 seconds (essential to let the capacitors discharge and the radio fully power down).
Toggle it OFF and wait for the "Searching" animation to lock onto a tower.

2. Verify Cellular Data & Line Settings

Sometimes, the logic governing multi-SIM or roaming gets toggled off due to a software glitch.

Go to Settings > Cellular.
Ensure Cellular Data is toggled ON.
If you use an eSIM/Physical SIM combo, tap your primary line and ensure "Turn On This Line" is active.
Check that Voice & Data is set to a supported protocol (LTE or 5G Auto).

3. Reseat the Hardware (SIM & eSIM)

Physical displacement is a common culprit for "SOS Only." Even a fraction of a millimeter misalignment can cause a communication failure between the SIM chip and the logic board.

Physical SIM: Eject the tray using a SIM tool, inspect the gold contacts for debris or scratches, and re-insert it firmly.
eSIM: While you can’t move it physically, you can "re-seat" the software profile. Toggle the line OFF in settings, wait 10 seconds, and toggle it back ON to re-initiate the handshake.

4. Reset Network Settings

This is the "magic bullet" for persistent software-side connectivity issues. It flushes all cellular caches, temporary files, DNS settings, and APN configurations.

Go to Settings > General > Transfer or Reset iPhone > Reset > Reset Network Settings.
Warning: This will delete your saved Wi-Fi passwords and Bluetooth pairings. It’s a clean slate for your network stack.

5. Update iOS to the Latest Version

Apple frequently bundles modem firmware updates within iOS releases. If you are running an outdated version, your phone might be trying to connect using outdated protocols.

Connect to a stable Wi-Fi network.
Go to Settings > General > Software Update.
If a patch is available, install it. This often fixes bugs introduced by previous versions that affect how the modem interacts with 5G infrastructure.

6. Manual Carrier Selection

By default, iPhones use "Automatic" network selection. If the phone gets "confused" or tries to connect to a restricted tower (e.g., a roaming partner with a broken agreement), it defaults to SOS.

Go to Settings > Cellular > Network Selection.
Turn Automatic OFF.
Wait for the list to populate (this can take a minute) and manually select your specific carrier. This forces the modem to ignore other broadcasts and focus solely on your provider.

7. Trigger a Carrier Settings Update

These are separate from iOS updates. They are small .plist files sent by your provider to update network frequencies and roaming configurations.

Ensure you are on Wi-Fi.
Go to Settings > General > About.
Stay on this screen for 30 seconds. If an update is available, a pop-up will appear saying "Carrier Settings Update". Tap Update.

8. Factory Reset (The Last Resort)

If you’ve tried everything and the "SOS Only" persists, you might be dealing with deep system corruption. A factory reset wipes the device and reinstalls a fresh copy of the OS.

CRITICAL: Back up your iPhone to iCloud or a Mac/PC first.
Go to Settings > General > Transfer or Reset iPhone > Erase All Content and Settings.
Set up the phone as "New" initially to see if the signal returns before restoring your backup.

Technical Indicators of Hardware Failure

If you have completed all 8 steps and the "SOS Only" remains, it is likely a hardware issue:

Empty Modem Firmware: Go to Settings > General > About. If the "Modem Firmware" field is blank, the baseband chip has likely failed.
Account Suspension: Contact your carrier. If you missed a payment or if there is a "SIM Swap" flag on your account, they will block the SIM from the network.

Pro Tip: Always check DownDetector first. If your carrier’s tower is down in your zip code, no amount of software resetting will bring your bars back!