Balance a useful photograph against a modest attachment limit
A 200 KB budget offers more room than the smallest form-image limits, but it is still a constraint that needs a purpose. This page starts the target-size compressor at 200,000 bytes. A product photograph for a small listing, an illustration in a report and a screenshot sent to support can all fit this kind of workflow, provided the result retains what the recipient needs to see.
Choose a local still PNG, JPEG or WebP and examine its source dimensions. Ask whether the receiving context needs the complete frame. A photograph with a small object surrounded by an empty table may benefit more from a deliberate crop than from aggressive compression of the whole scene. A technical illustration may need its margins and labels intact, so it calls for a different compromise.
Work backward from the important detail
For a product listing, identify the feature that matters: a connector, surface finish, pattern or small label. Inspect that region after each candidate output. An image can look attractive as a whole while losing the very detail that distinguishes one item from another. Avoid deciding solely from a fitted preview that makes every image the same on-screen size.
For a report screenshot, start by reading the smallest text the reader must use. If the output requires zooming beyond a comfortable level, reducing dimensions further may be counterproductive. Crop unnecessary interface areas where appropriate, or reconsider whether one screenshot should be divided into separate explanatory images outside this tool.
A family or event photograph has another priority: several small faces may need more usable pixels than one isolated portrait. The fact that a headshot met 200 KB at a particular quality does not establish a recipe for a group scene. Use the actual image rather than transferring a slider number between unrelated subjects.
Compare the two ways to spend bytes
Preserving dimensions leaves the pixel grid unchanged while the bounded search explores permitted encoding quality. That is appropriate when dimensions are required or when the image is already small enough. However, a large pixel grid with a low quality setting can show ringing, smeared texture or distracting blocks.
Allow resizing when fewer pixels are acceptable. A smaller result at a less severe encoding setting may appear cleaner at the intended display size. Compare both approaches using the same source. The tool does not silently choose that reduction when Preserve dimensions is the constraint you intended to keep.
Minimum quality defines how far the search may go, not what your eyes must accept. If no permitted result fits, the tool reports the closest measured output and a missed target. That outcome is preferable to hiding an unwanted dimension change or declaring that a file above the ceiling has succeeded.
Pick the format with the destination in mind
JPEG is useful for many opaque photographic copies. WebP is another option for supported recipients. PNG is useful for transparency and crisp graphics, but its lossless encoding has no lossy quality adjustment here. A photographic PNG can remain too large even when its JPEG equivalent would fit comfortably.
Small interface text can be a reason to retain PNG rather than force the image into a photographic encoding. Test the actual content. A chart with broad flat regions may compress differently from a scan of printed paper containing texture, noise and shadows. Neither “screenshot” nor “photo” is a complete description of its byte needs.
If JPEG is chosen for an alpha source, select the background and inspect the boundary. The transparent areas become ordinary colored pixels. Do not assume that a later website background can recover transparency from that flattened result. Use a supported alpha format when that is part of the delivery requirement.
A measured ceiling is not an exact size promise
Here 200 KB means 200,000 bytes. The tool measures encoded output rather than deriving a result from the source size or quality percentage. A smaller successful file is fine; the search is not intended to add unused information until every byte of the allowance is occupied.
The receiving application may display units differently or enforce additional rules. Read the actual output bytes and format, then compare those properties with the destination's instructions. A rejection can relate to dimensions or format even when the file is under the stated size ceiling. Renaming an extension cannot fix those underlying properties.
A picture already below the maximum may need no reduction at all. Re-encoding can still alter metadata, profiles and lossy pixels. Keep the original delivery file when it already meets the task, unless you have another deliberate reason to create a new copy.
Check the final copy rather than the search alone
Open the downloaded result in a normal viewer. Confirm its dimensions, orientation and type, then inspect the important region you identified at the beginning. Check text, faces or product detail at the likely use size. Download initiation is not evidence that the browser saved a complete file or that the recipient can use it.
The configured source ceiling remains 20 MiB, 12 megapixels and 6,000 pixels per edge for supported still PNG, JPEG and WebP. Browser memory can impose another boundary. A small target does not pre-authorize decoding an oversized input.
Source identifying metadata and the original ICC profile are not preserved by this re-encoding workflow. Keep a source master when those properties matter. For another budget, use Compress Image; for precise dimensions, use Resize Image. A saved source and a clear statement of the destination's needs are more useful than repeated exports of an already compressed copy.