DEV Community: Zippic

Why a QR Code Stops Scanning After Image Compression

Zippic — Sat, 14 Nov 2026 20:21:06 +0000

A QR code can look intact in a compressed event flyer and still fail on a phone. The three corner markers remain visible, the text around it looks acceptable, and the file passes the upload limit. Yet the camera cannot reliably separate the smaller squares that carry the data.

That makes a QR-bearing image a different optimization problem from an ordinary photograph. Visual similarity is useful, but successful decoding of the final delivered image is the acceptance test. A smaller file is not an improvement if people cannot use it.

Protect the grid and its quiet zone

The small squares in a QR code are called modules. A scanner needs to distinguish their positions and identify the symbol against its surroundings. DENSO WAVE, the developer of QR Code, specifies a clear margin four modules wide on every side of a standard QR code. That margin is the quiet zone, not disposable whitespace.

Cropping tightly around the black pattern removes useful structure. Placing a caption, border, or busy photograph immediately against it can also interfere with detection. Preserve the quiet zone as part of the asset when placing a code in a flyer or slide. An opaque light background is more predictable than transparency when the destination background may change.

For a hypothetical grid 29 modules wide, adding four modules on each side produces a total width of 37 modules. Rendering each module as four pixels produces a 148-pixel-wide image including the margin. This is arithmetic for planning an export, not a universal minimum size or a promise that every scanner can read it.

Keep the original generated QR asset. If its intended display size changes substantially, regenerate it for the new layout rather than repeatedly resizing an already compressed screenshot.

Separate resampling damage from encoding damage

Resizing changes where module boundaries fall in the pixel grid. When the new dimensions do not align cleanly with that grid, a resampler may create gray transition pixels or make adjacent modules uneven in width. Heavy reduction can leave too few pixels to represent the pattern reliably.

Lossy encoding creates a different risk. Ringing, small blocks, or smudged transitions can appear around high-contrast edges even when the image dimensions stay unchanged. A photograph can tolerate some of those changes while a small QR code cannot.

An integer number of source pixels per module is a useful starting point for a raster export. It does not guarantee an integer mapping on every screen: page layout, display density, and browser scaling can resample the image again. Avoid treating a clean-looking source file as proof that the published version will work.

When investigating a failure, compare exports with one variable changed at a time. Keep the dimensions constant while trying a different encoding setting. Then keep the encoding choice constant while changing the layout or source size. If an entire flyer must shrink, enlarge the code within the design before exporting again instead of expecting compression settings to recover missing modules.

Compress a copy without assuming QR-aware processing

For a one-off file, zippic provides a browser-local compression workflow: choose the image, select an output format, optionally change dimensions under Resize Settings, then use Start Compress and download the result. Its public page says images are not uploaded to a server for compression and no account is required.

For an isolated QR graphic, PNG is a reasonable first output to evaluate because the asset consists mainly of sharp, flat-color boundaries. This does not mean every PNG export is automatically optimal or that a tool's PNG option guarantees unchanged pixels. Compare the downloaded result, not just the format label.

Begin without resizing. If the resulting file already meets the destination's requirement and scans reliably, there is no reason to reduce its dimensions further. For a photograph-heavy flyer, a photo-oriented output may be practical, but the embedded code needs its own close inspection and scan test.

The compressor's public page does not describe a QR-aware resizer or a QR validation feature. Do not assume it will preserve module alignment or detect a broken code. It also has no exact target-file-size setting; an upload ceiling requires checking the actual download and adjusting as necessary.

Test the version people will actually receive

Scan the downloaded file at the size it will appear, using a second device when the image is displayed on a screen. Check the decoded destination before opening it; recognition of some QR payload is not enough if the asset contains the wrong link.

Then test the delivery channel. A messaging service, publishing platform, or social network may resize or re-encode the upload. Open the published image through the normal viewing path and scan that version too. For printed material, test a physical proof at the intended size under realistic lighting and distance rather than scanning an enlarged desktop preview.

If the delivered version fails, return to the layout or original QR asset. Restore the quiet zone, allocate more space, or reduce unnecessary detail in the surrounding design. Keep a readable text URL next to the code where practical so the destination remains accessible when scanning is inconvenient. That fallback should remain live and legible in the final export as well.

Sources: DENSO WAVE: code area and quiet zone; DENSO WAVE: module size and scanner limits.

Disclosure: This article was prepared on behalf of zippic.

Free Image Compressor in the Browser: When “No Upload” Actually Matters

Zippic — Thu, 05 Nov 2026 01:54:37 +0000

Most free image compressor sites look the same from the outside: a drop zone, a progress bar, a download button. Underneath, they split into two architectures. Some send your file to a server, compress it there, and send it back. Others ship the encoder to your browser and never transmit the image at all. Both are legitimate designs. The useful question is when the difference is worth caring about, because “no upload” is often marketed as if it were always the deciding factor, and it isn't.

What an upload-based compressor does

Server-side tools have real advantages. They can run any encoder written in any language, they don't depend on the visitor's hardware, and many of them have been tuned for years. TinyPNG is the best-known example. Its site explains that it quantizes PNGs to reduce the number of colors, turning 24-bit images into 8-bit indexed ones, and strips unnecessary metadata. It also states its retention policy plainly: uploaded images are kept for a maximum of 48 hours and then permanently deleted. The free web tool accepts up to 20 images at a time, each up to 5 MB, with paid Web Pro and Web Ultra plans for more.

That is a reasonable deal for a lot of work. If you are compressing a hero image for a blog post that will be public in an hour, a 48-hour retention window on someone else's server does not change your risk in any meaningful way.

When “no upload” matters

The calculation changes when the image itself is sensitive, or when sending it anywhere is a problem regardless of what happens to it afterward.

Unreleased product shots, internal dashboards, and screenshots of admin panels are the obvious cases. A screenshot taken for a bug report often contains customer names, email addresses, or a token in a corner nobody looked at. Scanned IDs, contracts, and medical paperwork are another category. People compress these all the time to get under upload limits on government or insurance portals, and they are exactly the files that should not take a detour through a third party.

There is also the organizational angle. Many companies restrict which external services may receive company data. A developer can be fairly sure that a compression service deletes files promptly and still be in breach of policy for using it. A tool that processes files locally avoids the question entirely, because nothing leaves the device.

Then there are practical reasons that have nothing to do with privacy. A 30 MB camera file on a slow connection spends most of its “compression time” in transit: upload the whole file, wait, download the result. Doing the work locally removes both transfers. Per-file size caps on free server tools exist partly because of that bandwidth cost; a browser-based tool is limited by device memory instead.

How browser-based compression works

Two platform features make this practical. WebAssembly lets mature encoders written in C, C++, or Rust run inside the browser at usable speeds; open-source projects such as MozJPEG, libwebp, OxiPNG, and libavif are common candidates for this kind of build. Web Workers move the encoding off the main thread so the page stays responsive while a large image is processed.

The trade-offs are real. Memory is finite: a decoded image costs roughly width × height × 4 bytes no matter how small the original file was, so a 24-megapixel photo occupies close to 100 MB as raw pixels. Phones are slower than servers. Encoder modules add download weight to the page. Well-built local tools respond by recommending a per-file ceiling and processing batches with limited concurrency, rather than promising unlimited capacity.

Don't take “no upload” on faith

Any site can write “your files never leave your device” in its hero section. Checking takes about a minute:

Open DevTools and switch to the Network tab.
Compress an image of known size, for example a 4 MB JPEG.
Look for a request with a payload of roughly that size. Filtering by Fetch/XHR and sorting by size makes it easy to spot.
For a stronger test, load the page, disconnect from the network, and compress again. If it still works, the processing is local.

You will see some requests regardless: analytics, ads, fonts. Those are not your image. What you are looking for is a request whose body is the size of your file.

Quality is mostly about settings, not location

A common assumption is that server tools produce better output because they have more compute behind them. In practice, output quality depends on the encoder and its settings far more than on where the encoder runs. The same encoder at the same quality setting produces essentially the same result on a server or in a WebAssembly module. What does vary between tools is the amount of control you get: whether you can set quality yourself, which output formats are offered (WebP and AVIF matter for most web work), and how metadata is handled.

One behavior surprises people regardless of architecture. Compressing a JPEG that has already been heavily compressed can produce a larger file, because re-encoding at a higher quality setting than the original used adds bytes without adding detail. Start from originals whenever you can.

A short decision guide

Public images in small batches: use whichever tool gives you output you like.
Sensitive images, or files covered by a data-handling policy: process locally.
Large originals on a slow connection: local processing saves the round trip.
Hundreds of files: check the batch and size limits of a server tool's free tier; with a local tool, check that batches run with limited concurrency so the tab doesn't run out of memory.

Trying one

If you want a browser-based option to test with the DevTools method above, zippic is a free image compressor that runs client-side using WebAssembly and Web Workers. There is no sign-up, it handles JPG, PNG, WebP, GIF, AVIF, BMP, and common camera RAW formats, and quality is adjustable. The example on its homepage takes a 2.95 MB image down to 247 KB. The project recommends keeping individual files under 50 MB, which reflects browser memory rather than a usage quota.

Whichever tool you end up using, the Network tab is the most reliable answer to the question of where your image went.

APNG vs GIF for Small Web Animations: Transparency, Loops and File Size

Zippic — Mon, 26 Oct 2026 09:56:58 +0000

Spinners, success checkmarks, a waving mascot on an empty state, chat stickers: small looping animations still get exported as GIF by default, mostly out of habit. GIF works everywhere, but it was designed in 1987, and its limits show up quickly once the animation has soft edges or sits on a dark background.

APNG (Animated PNG) is the other format that every major browser plays natively without JavaScript. Here is when it beats GIF, when it doesn't, and a few practical details about loops, timing and file size.

TL;DR: use APNG when the animation has soft edges or translucency, set num_plays to 1 for one-shot animations, keep frame delays in multiples of 10 ms, and trim frames before you compress.

What GIF can and can't store

From MDN's image format guide:

Each GIF pixel is an 8-bit index into a palette of 24-bit colors, and the palette has at most 256 entries. Anything with gradients or many shades gets dithered.
Pixels are opaque unless one palette index is designated as transparent, and pixels with that index are fully transparent. There is no partial transparency.

That second point matters most for UI work. Anti-aliased outlines, soft shadows and translucent highlights all rely on partial alpha. In a GIF, every pixel has to snap to fully opaque or fully transparent, which is where jagged edges and the familiar light halo around stickers come from. The halo usually appears when the artwork was flattened against a white background before export and then placed on a dark one.

What APNG adds

APNG extends PNG, so each frame can use any PNG color mode, including true color with an 8- or 16-bit alpha channel. Compression is lossless. MDN describes APNG as a good fit for "basic animations that do not need to synchronize to other activities or to a sound track, such as progress indicators, activity throbbers, and other animated sequences".

The comparison below is a demonstration from a single 320×270 frame with an anti-aliased outline and a soft, semi-transparent drop shadow. For the GIF, semi-transparent pixels were flattened onto a white matte and then cut with a 1-bit transparency threshold, which is how a typical GIF export behaves. The other side is the original PNG. Both sit on a #1f2937 background, and the boxed area on the lower-left outline is enlarged 3x. The GIF shows a light, jagged fringe along the outline, and the shadow is gone. The PNG keeps smooth edges and the shadow.

Browser support

MDN lists APNG support from Chrome 59, Edge 12, Firefox 3, Opera 46 and Safari 8. The MIME type is image/apng, and the file can keep the .png extension. You use it like any other image:

<img src="/img/loader.png" width="48" height="48" alt="Loading">

Where GIF still makes sense

If a file has to pass through a system you don't control that only accepts .gif, such as an upload field or a third-party integration, GIF is the safe choice. And if you are optimizing purely for bytes on a photographic or detailed animation, MDN points out that animated WebP and AVIF compress better than both. APNG sits in the middle: lossless, full alpha, and universally supported in current browsers.

Loops and timing: two details worth knowing

Loop count. APNG stores a num_plays value. According to the W3C PNG specification, 0 means play indefinitely, and any other number means the animation stops on its final frame after the last play. That makes a one-shot micro-animation easy: set loops to 1 and make the last frame the resting state. A success checkmark plays once and stays checked, with no JavaScript needed to swap in a static image. Loaders want 0.

Frame delay. Each frame's delay is stored as a fraction of a second (delay_num / delay_den). Many encoders write it in hundredths of a second, so a 33 ms delay may end up as 30 ms. Picking multiples of 10 ms (50, 80, 100) keeps the timing you set identical to what ends up in the file.

If you also respect prefers-reduced-motion, you can swap in a static image with <picture>:

<picture>
  <source srcset="/img/mascot-still.png" media="(prefers-reduced-motion: reduce)">
  <img src="/img/mascot.png" alt="Mascot waving">
</picture>

Building an APNG from PNG frames

Export each frame as a transparent PNG at the final size, then assemble them. Command-line tools like APNG Assembler work well in a build pipeline. For a one-off, a browser tool is quicker. zippic's APNG Maker is one option. It processes images locally in the browser without uploading them, and lets you set the canvas size, a default delay, per-frame delays, the loop count and a fill color.

A few defaults to change:

Canvas defaults to 640×480. Set it to your frame size. Frames are scaled to fit and centered, so frames that don't match the canvas get padded with the fill color.
Fill Color defaults to #00000000 (fully transparent). Leave it that way if you want alpha.
Default Frame Delay defaults to 30 ms, which is fast for most UI motion. Start around 80–100 ms and adjust individual frames in the frame list.
Loop Count defaults to 0 (infinite). Change it to 1 for one-shot animations.

Keeping the file small

Full color plus alpha can get heavy, so cut at the source first:

Trim the canvas. Empty transparent margins still cost bytes in every frame.
Drop frames. A 10-frame loader at 100 ms can read just as well as 20 frames at 50 ms, at roughly half the frame data.
Hold instead of repeating. For a pause, use one frame with a longer delay rather than several identical frames.
Then compress. zippic's homepage compressor has an APNG output format with a quality slider. In the test shown below, the 10-frame example went from 15.33 KB to 5.52 KB at 75% quality. Results depend heavily on the artwork, so preview the output to check that the animation and edges still look right.

A real-world constraint: LINE stickers

For a platform that requires APNG, look at LINE. Its Creators Market accepts animated stickers only as APNG, with a published spec: 5–20 frames per sticker, 1–4 loops, at most 4 seconds of total playback across all loops, a maximum of 320×270 px with at least one side of 270 px or more, a transparent background, and up to 1 MB per file. A GIF won't upload, and an APNG left at the default infinite loop gets rejected too. It's a useful checklist even if you never ship a sticker, because it's a sensible budget for any small looping UI animation.

Quick decision guide

Soft edges, translucency, or a dark or variable background: APNG
Must pass through a GIF-only pipeline: GIF
Bytes matter most and you can provide fallbacks: consider animated WebP or AVIF
One-shot animation that should come to rest: APNG with loop count 1

Sources

MDN, Image file type and format guide: https://developer.mozilla.org/en-US/docs/Web/Media/Guides/Formats/Image_types
W3C, PNG Specification (Third Edition), acTL and fcTL chunks: https://www.w3.org/TR/png-3/
LINE Creators Market, Animated sticker guidelines: https://creator.line.me/en/guideline/animationsticker/

How to Compress an Image to 100KB (or 50KB, 20KB) Online

Zippic — Sat, 17 Oct 2026 14:00:52 +0000

You're filling in a job application, a visa form or an exam registration, and the upload box comes back with: "File size must not exceed 100KB." Your phone photo is 3MB. Sound familiar?

This guide covers why these limits exist, what actually controls an image's file size, and how to get a photo under 100KB, 50KB or even 20KB with zippic. zippic is a free image compressor that runs entirely in your browser. Your photo is never uploaded to a server, and you don't need an account.

Why do websites limit images to 100KB?

Small upload limits show up in a few places:

Job, visa and exam portals. Government and recruitment sites take thousands of photos and scanned signatures, often on older systems. Strict caps such as 20KB, 50KB or 100KB keep storage and bandwidth under control. Many of these portals also set pixel dimensions or ask for JPG only.
Email. Mail providers cap total attachment size. A few small images fit easily, while several full-resolution photos may not.
Web forms and profile photos. Contact forms, CMS uploads and avatar fields often set a low maximum so pages stay fast.

The exact rules vary from portal to portal, so always read the official instructions first: file size, pixel dimensions, format and background. Then compress to match them.

What determines an image's file size?

Three things matter, roughly in this order:

Pixel dimensions. The phone photo in the example below is 3376 Ã— 4239, about 14.3 million pixels. Resized to 1200 Ã— 1507, it has about 1.8 million. Fewer pixels means much less data, so resizing is the most powerful lever by far, especially for small targets like 20KB.
Format. JPG and WebP are lossy formats designed for photos, and they can get very small. PNG is lossless. That's great for screenshots and graphics, but a PNG photo is usually far larger than a JPG of the same photo.
Quality level. Lossy formats let you trade detail for size. Lowering quality shrinks the file, but if you push it too far you get blur and blocky artifacts.

Image content plays a part too. A plain-background portrait compresses much smaller than a detailed landscape at the same dimensions and quality. That's why no setting gives exactly 100KB for every photo.

Step by step: compress an image to 100KB with zippic

zippic doesn't have a "type in a target KB" box. Instead it shows you the compressed size right after each run, so you adjust and re-run until you're under your limit. With the two controls below, that usually takes a couple of tries.

Open the zippic image compressor and click "Choose an image or drag & drop it here". zippic accepts JPG, PNG, WebP, AVIF, JXL, GIF, HEIC and RAW files. Once loaded, it shows the original file size and pixel dimensions (in the example below: 1.46 MB â€¢ 3376Ã—4239).

The zippic compressor before upload: Format, Quality (default 75%) and Resize Settings.

Choose the output format. Under Format, keep JPG (the default) for application portals. Most of them only accept JPG/JPEG. WebP, AVIF, JXL and PNG are also available.
Set the quality. The Quality slider runs from 50% to 100% and starts at 75%. For small targets, start around 60â€“75%.
Resize the image. Turn on the Resize Settings switch and enter a Width in pixels. If you leave Height empty, zippic keeps the original aspect ratio. For example, a 3376 Ã— 4239 photo resized to a width of 1200 comes out as 1200 Ã— 1507.
Click "Start Compress". zippic shows the Compressed Size, the new dimensions and the Compression Ratio next to the original. In the example below, a 1.46 MB JPG (3376 Ã— 4239) at JPG, quality 75%, width 1200 came out at 70.60 KB (1200 Ã— 1507), a 95.27% reduction. That's well under a 100KB limit on the first try.

JPG, 75% quality, 1200 px wide: 1.46 MB â†’ 70.60 KB.

Drag the comparison slider to check the compressed image against the original.

Check against your limit. Still too big? Lower the width or the quality and click Start Compress again. You don't need to re-upload. Comfortably under? Raise the quality a little to get a sharper image.
Click "Download". The file is saved with a _compressed suffix (e.g. photo_compressed.jpg).

Everything happens on your device, which matters when the image is a passport photo, an ID scan or a signature.

Why this works: in the example above, reducing the width from 3376 px to 1200 px did most of the work. At the default 75% quality, the file still dropped from 1.46 MB to 70.60 KB. Dimensions do the heavy lifting, and quality fine-tunes.

Tips for hitting an exact target

Resize first, then fine-tune quality

Quality alone often isn't enough, because the slider only goes down to 50%. A full-resolution phone photo usually needs resizing too. So pick dimensions that get you close, then use the quality slider for the last few kilobytes. If the portal specifies pixel dimensions (for example a particular photo size), use exactly those. Many photo specs also fix the aspect ratio. If yours does, crop first with the image cropper, which has preset sizes for ID photos and exam registrations.

JPG vs WebP

JPG is the safe choice for any form, portal or email recipient. It's universally accepted.
WebP often produces smaller files than JPG at similar visual quality, and it's a good choice for your own website. Many official portals don't accept it, though, so check the allowed formats before you use it.
PNG only makes sense for graphics, screenshots or images that need transparency. For a photo under 100KB, it's rarely the right tool.

Quality levels to try

75%: a good starting point that looks clean for most photos.
60â€“70%: usually still fine for profile and ID-style photos.
50%: the slider's minimum. Use it for very small targets like 20KB, together with a smaller width.

If you hit 50% and the file is still too big, reduce the width again rather than fighting the quality slider.

Leave a small safety margin

zippic's size readout uses 1 KB = 1,024 bytes. Some portals count 1 KB as 1,000 bytes, so a file shown as 99 KB could be read as just over 100 KB. Aim for roughly 5% under the limit, e.g. about 95 KB for a 100KB cap.

Common size targets (approximate guidance)

These are rough starting points for a typical JPG photo, not guarantees. Detailed images need smaller dimensions or lower quality, and simple portraits can go bigger. Always check the result zippic shows.

Target size	Starting width (long side)	Starting quality	Typical use
20KB	~400â€“600 px	50â€“60%	Signatures, small ID/exam photos
50KB	~600â€“800 px	50â€“70%	Application photos, avatars
100KB	~800â€“1200 px	50â€“75%	Job/visa portals, forms
200KB	~1200â€“1600 px	60â€“75%	Email images, documents, web uploads

Guidance only: these are approximate starting points, not measured results. Real sizes vary with image content, so always check the Compressed Size zippic shows.

Troubleshooting

The compressed file is larger than the original.
This happens when the source has already been heavily compressed, for example an image saved from a chat app. Compressing it again can add data. Start from the original photo if you can, and resize it down.

I can't get below 20KB.
Lower the width further (try 400 px or less) and set quality to 50%. Also check that the format is JPG, not PNG.

The portal rejects my file even though it's under the limit.
Check the other rules: required format (JPG/JPEG), exact pixel dimensions, aspect ratio and file name. Use the image cropper to match a required size.

My iPhone photo is HEIC and the portal wants JPG.
Either load it into the compressor and choose JPG output, or convert it first with the HEIC to JPG converter.

The image looks blurry or blocky.
You've pushed quality too low for that size. Raise the quality slightly and reduce the width a little instead. Smaller but clean usually beats larger but blocky.

My file is a PDF, not an image.
Use the document compressor for PDF, Word and PowerPoint files, or turn PDF pages into images with PDF to image.

Need to compress many photos at once?

If you're preparing a batch (several documents for one application, or product photos for a store), use the bulk image compressor. It has the same Format, Quality and Resize Settings controls and processes multiple images in your browser. When it's done, Download All grabs every file.

In the example below, three files went through at JPG, quality 75%, width 1200, and every one landed under 100KB. A 1.46 MB JPG became 70.60 KB (95% smaller), a 2.76 MB PNG cover became 65.04 KB (98%), and a 1.05 MB PNG became 72.48 KB (93%). Note that the PNGs were converted to JPG output here, which is a big part of why they shrank so much.

Bulk compression: three images, one setting, all under 100KB. To crop a batch to the same size first, use the bulk image cropper.

For more on choosing formats, see Best Image Formats for the Web. For ID-photo sizing, see zippic's ID photo cropping guide.

FAQ

How do I compress an image to 100KB without losing quality?
Resize the image to the dimensions you actually need (often around 800â€“1200 px wide for a photo), keep JPG, and start at about 75% quality. Because the pixel count drops so much, you can usually reach 100KB with only a modest reduction in quality.

How do I reduce a photo to 20KB or 50KB?
Make the image much smaller in pixels first, roughly 400â€“600 px wide for 20KB or 600â€“800 px for 50KB, then lower the quality toward 50â€“60%. Check the compressed size and adjust until you're under the limit.

Does zippic upload my images to a server?
No. zippic compresses images locally in your browser, so your photos stay on your device. It's free and needs no sign-up.

Which format should I use for application portals: JPG, PNG or WebP?
Use JPG unless the portal says otherwise. JPG is accepted almost everywhere and is small for photos. WebP can be smaller but isn't accepted by many portals. PNG photos are usually much larger.

Why is my compressed image bigger than the original?
The original was probably already heavily compressed, so compressing it again doesn't help and can add data. Use the original photo where possible, and reduce its dimensions to make it smaller.

Conclusion

Getting a photo under 100KB, 50KB or 20KB comes down to two moves: resize to sensible dimensions, then fine-tune quality, keeping JPG for anything official. zippic shows the result instantly and keeps your files on your device. If you need a free, no-upload option, zippic's image compressor is worth a try.