The short answer
Open the image compressor, set Mode to Target size (KB), keep the target at 200, pick an output format (see the table below), add your files and press Compress. A photo at 2400×1600 came out at 202,028 bytes in our test — under the target. Whether 200 KB is enough for your image depends on its type: photos compress easily, screenshots compress well as WebP, and a transparent PNG kept as lossless PNG may not shrink at all.
What "200 KB" means here: KB vs KiB
Upload forms rarely say which "KB" they mean. This tool counts in binary units: the target value is multiplied by 1024, so a target of 200 means 204,800 bytes (200 KiB), and the sizes shown in results use the same 1024-step convention with rounding (the row "197 KB" was 202,028 actual bytes in our test). Some systems check against 200,000 bytes (decimal KB). If your form does that, play safe: enter a target of 195 (199,680 bytes) and, for anything strict, download the file and check its real byte size yourself — the displayed value is rounded, the file on disk is the truth.
Steps in the tool
- Open. Go to the image compressor. Files are processed in your browser; nothing is uploaded. Limits: 20 files per batch, 20 MB and 25 megapixels each.
- Set the mode. Under Mode, choose Target size (KB). The Target size per image (KB) box appears with a default of 200 — keep it or type your own.
- Pick the output format. Output format: *Same as input* keeps the file type; *JPG*, *PNG* or *WebP* converts every file. Rule of thumb from our tests: JPG or WebP for photos, WebP for images that must stay transparent, and expect little change if you keep a screenshot as PNG.
- Add files and compress. Drag the files in (or click the drop area) and press Compress. Each row shows the size change and the quality used, for example
1.61 MB → 197 KB (-88%) · Q22. - Download and verify. Download each file (or all as a ZIP). If the receiving system is strict, check the downloaded file's byte size — that is the number that counts.
- Read honest failures. A row saying
already well compressed — original keptmeans the tool could not shrink that file without changing its format or losing the condition you asked for (for example lossless PNG), so it kept your original instead of pretending.
Our test results (2026-11-10, desktop Edge)
We drew three original synthetic samples — a photo-like scene, a transparent logo and a text screenshot — and ran them through the tool at target 200. All numbers below are actual file bytes read back from the downloaded output, not the rounded display:
| Sample | Pixels | Original bytes | Output format | Result | Actual bytes | Under 204,800? |
|---|---|---|---|---|---|---|
| Photo (JPG) | 2400×1600 | 1,683,390 | JPG (same) | 197 KB, Q22 | 202,028 | Yes |
| Transparent logo (PNG) | 2000×1400 | 325,503 | PNG (same) | kept original | 325,503 | No — honest failure |
| Transparent logo (PNG) | 2000×1400 | 325,503 | WebP | 200 KB, Q76 | 204,422 | Yes — transparency kept |
| Transparent logo (PNG) | 2000×1400 | 325,503 | JPG | 190 KB, Q94 | 194,432 | Yes — flattened to background |
| Text screenshot (PNG) | 2200×1400 | 543,857 | PNG (same) | kept original | 543,857 | No — honest failure |
| Text screenshot (PNG) | 2200×1400 | 543,857 | WebP | 198 KB, Q76 | 202,956 | Yes |
| Photo (WebP, already small) | 2400×1600 | 27,020 | WebP (same) | kept original | 27,020 | Already under target |
As a comparison, the quality-level mode at the default Q80 turned the same photo into 1,244,344 bytes (1.19 MB) — smaller, but nowhere near 200 KB. That is the difference between the two modes: quality mode compresses by a fixed level; target mode searches for the largest quality that still fits your number.
Why the transparent PNG refused the target
PNG is a lossless format: re-encoding rewrites the file but must reproduce every pixel exactly, so size barely moves. Our logo stayed at 325,503 bytes and the tool said so instead of handing back a fake result. To actually get that logo under 200 KB you must give something up:
- Switch to WebP — came out at 204,422 bytes (Q76) and kept the transparency (we verified the corner pixels are still transparent). Usually the best trade for logos and UI graphics.
- Switch to JPG — came out at 194,432 bytes (Q94), but JPG has no alpha channel: the tool flattens transparency onto a white background (verified in our output). Fine for printing or embedding on white; wrong for layering.
- Resize smaller first — fewer pixels means a smaller lossless PNG. Use the image resizer if the destination allows smaller dimensions.
- Re-export from the source — a flat-color logo re-exported from its design file is often a fraction of the PNG-from-photo size.
Lossy vs lossless, and what changes what
| Lever | What it does | Trade-off | In this tool? |
|---|---|---|---|
| Quality reduction (JPG/WebP) | Drops fine detail; big savings on photos | Irreversible softening/artifacts | Yes — target mode finds the quality for you |
| Format conversion PNG→JPG | Removes alpha, adds compression | Transparency lost | Yes — flattened onto white |
| Format conversion PNG→WebP | Keeps alpha, compresses well | Rare compatibility issues on very old software | Yes |
| Keeping PNG | Lossless, safe for text and hard edges | Barely shrinks; KB targets often impossible | Yes — but expect honest failures |
| Fewer pixels | Scales down dimensions | Cannot be undone | No — use the image resizer |
| Different container (AVIF etc.) | Modern formats compress further | Not everywhere supported | Not here — the image converter handles AVIF output |
Choose by scenario
- Portal/exam/job upload demanding “JPG under 200 KB” — target mode, output JPG, target 200; if the form checks decimal bytes, target 195. Photos work directly; documents that started as PNG scans convert cleanly but text edges soften a little at strong compression.
- Logo/graphic that must stay transparent and small — target mode, output WebP (transparency kept). If the destination refuses WebP, JPG-on-white or a resized PNG are the fallbacks.
- Screenshot to send by mail/chat — target mode, output WebP; our 531 KB screenshot became 202,956 bytes at Q76 and text stays readable. Keep PNG only when every pixel must stay identical (design handoff), and then compress differently.
- File already under the target — leave it alone. The tool detects this and keeps your original instead of re-encoding for nothing.
Known limits and failure handling
- Inputs: JPG, PNG, WebP only; up to 20 files, 20 MB and 25 megapixels each. Anything else needs the image converter first (GIF/BMP/AVIF/SVG inputs are supported there).
- No password/EXIF stripping guarantee: re-encoding through the browser canvas drops most original metadata, but do not rely on this for privacy — remove sensitive data explicitly before sharing.
- Quality numbers (Q values) come from the browser's own encoders and differ between browsers; the byte size is what matters, not the Q value.
- If a row reports the closest honest result but still misses the target, no quality setting will fit at the current pixel size — resize smaller or convert format.
- Everything runs locally in the browser tab; processing time depends on your device.
Try it with our samples
The sample files below are the exact inputs from our test runs (YYSI-made synthetic drawings, no third-party material). Download them, run the tool with target 200, and compare your byte counts with the table above.
- photo-2400x1600.jpg — photo-like sample, 1,683,390 bytes — Download sample · 1683390 bytes
- transparent-logo-2000x1400.png — transparent logo, 325,503 bytes — Download sample · 325503 bytes
- text-screenshot-2200x1400.png — text screenshot, 543,857 bytes — Download sample · 543857 bytes
- photo-2400x1600.webp — already-small WebP, 27,020 bytes — Download sample · 27020 bytes
SHA-256 checksums are shown next to each download link so you can confirm the file you received is the file we tested.
Sources & verification
- YYSI Image Compressor (the tool this guide drives; control labels and behavior observed in source and live page) — Sources checked 2026-11-10
- MDN: canvas.toBlob — quality argument is encoder-dependent; JPG/WebP encoding is lossy — Sources checked 2026-11-10
Sources checked All numbers in the sample table come from YYSI's own test runs on 2026-11-10 (Windows 11, desktop Edge) against the workspace build whose script hashes match the live page (tools-common 2a07d94791af, engine 9a58f43b476b). Output sizes were read from the downloaded file bytes, not the rounded display. Sample images are YYSI-made synthetic drawings, provided for download; no third-party material.
Read our editorial standards or send corrections to [email protected].