Lowering the export quality made the small labels in my screenshot blurry, even though the pixel dimensions stayed unchanged. I’m preparing it for an upload form that rejects the original file size, and resizing isn’t an option. What compression settings or approaches should I try next without changing the width and height?
The thing people get wrong about shrinking an image is treating the smallest possible file as the best result. I’d rather have a readable picture that meets the upload rules than an impressively tiny one that makes everyone look like they were photographed through a shower curtain. The useful distinction is between meeting a requirement and chasing a lower number.
I start by separating the requirements. A file-size ceiling tells me how much data the upload can contain. Required pixel dimensions tell me how wide and tall the image must be. Those are separate checks, and satisfying one doesn’t establish that I’ve satisfied the other. That distinction matters before I touch a compression setting, not after a form rejects the result.
I also wouldn’t assume that every image needs the same treatment. A regular photo, a picture containing small lettering, and a transparent logo give me different things to protect. Getting them below an upload limit is only part of the job.
Decide what must survive before shrinking anything
For me, the original stays untouched. I want a smaller upload copy, not a replacement that leaves me stuck with whatever compromises I accepted. That’s a fairly dull precaution, which is usually the best kind.
Next I’d check whether the image has more resolution than the destination needs. The maximum-width setting deserves a look before I keep lowering quality on a huge picture. Reducing unnecessary width may make more sense than applying increasingly harsh compression, provided I’m still meeting any required dimensions. I wouldn’t call that an automatic fix, just a different adjustment worth checking.
Format needs its own inspection. The supplied description warns that PNG input can become JPEG output. For an ordinary photo, that may be acceptable. For a logo whose transparent background matters, I would stop and check the downloaded format rather than assume the original format survived. A smaller file isn’t much of a win if it no longer does the job.
Then comes the visual check. I’d view the download at the size people will actually see it and look specifically at faces, fine edges, and small lettering. The saved kilobytes can tell me whether I’m under the ceiling. They can’t tell me whether those details still look acceptable.
The same caution applies to a batch. I’d try a detailed image before sending everything through the same settings. Batch processing is convenient, but convenience isn’t evidence that every picture will tolerate the same reduction.
The controls sound useful; the broader claims need restraint
For the actual compression step, the Clever Humanizer tool is described as accepting JPG, PNG, and WEBP files, with either a quality setting or a target file size. It also offers batch processing. Those are the relevant controls for this problem, rather than a reason to treat it as a full photo editor.
The target-size option is the part I’d reach for when a form gives a specific limit. For a 200 KB requirement, the described procedure is to select “Fit a size limit” and enter 200. I’d still check the resulting download. Choosing a target and confirming the finished file are separate steps in my book.
With a strict 1 MB allowance, I’d leave some headroom instead of aiming exactly at the boundary. I don’t see a benefit in making the upload limit a precision sport.
The service is presented as completely free, without signup or watermarks, and as processing images inside the browser rather than uploading them to a server. I haven’t independently verified those claims, so I wouldn’t turn them into personal guarantees, especially the processing claim. They describe the offered workflow, not a privacy audit I’ve performed.
My verdict: I’d consider it for a straightforward oversized-image problem, but I’d trust the inspected download more than the description. Meeting the size limit while preserving the details and format I need is success. Merely producing a smaller file isn’t.
6 Likes
You do not want to compromise the quality of your exports to reach the suggested total above. For small images you should look into optimizing the original image losslessly using PNG format. This will result in a smaller file size without reducing the pixel dimensions or blurring any text. If your image has already been optimized there may not be enough reduction in size.
If you’re compressing the copy that already has blurry labels, go back to the original screenshot first. Saving that blurry copy as PNG will preserve the blur, not undo it. That’s the caveat I’d attach to @xzenshellx’s PNG suggestion: the starting file matters as much as the output format.
To keep pixel dimensions the same but reduce file size. However, the width and height just tell us how big the grid of pixels is. Lossy compression can cause the picture to look different as the colours in the grid will change. The text on the image will become less legible. A quality slider may not be the best way to control the resolution.
If your screenshot is still a clean PNG then it might be worth looking into lossless optimisation. If you have a JPEG with blurry text there’s nothing you can do to get that detail back. If you can take a new screenshot then you’ll be able to get a cleaner image. Exporting a JPEG multiple times at a lower quality will make it worse.
Some tools which say they compress PNGs actually reduce the number of colours used. This can save space without reducing the size, however the subtle shading next to the text may change. When looking for a tool to do this look for one that does lossless compression.
Without changing the size of the image we can consider what we’re losing. We need to know what format we had originally, what file size we had and what the maximum upload size is. This will tell us if we need to make a small change or if the form wants us to compress it more than we can with an untouched screenshot.
A screenshot of plain text will take up far less space than one with a photo or patterned background. As long as the size remains the same you do not need to worry about including unnecessary visual elements. Unless you have a requirement to upload a completely unedited screenshot.
This advice is helpful for ensuring your labels are kept safe. However, if you cannot lose any more data by optimising your PNG file, try editing your screenshot to help reduce the size. If your screenshot includes something like a desktop wallpaper, decorative picture or unrelated preview pane you could try using a solid colour fill instead. This will help reduce your file size without affecting your labels. Just ensure that you have kept the canvas the same. Whilst this is an edited version of your screenshot, you are changing the content rather than asking the encoder to lose quality throughout.
It is important to note that this does not mean the file has to be the same size and exactly the same pixels. If you don’t mind the size and your labels being readable then this can give you some flexibility. However, if this is evidence or a verification submission, or anything that needs to accurately portray the original screen then you should not edit your file. In this case I would disagree with the statement that having a target size will guarantee that you can upload. The form could just have a strict limit and your unedited file in an accepted format may not fit within this.
Do not make assumptions about what you see in your preview. Whilst you can reduce the file size without affecting pixel dimensions, the exported image may not be the same as the image you are seeing in the form.
Open up your original, and your reduced export at 100% and compare a small piece of text between the two images. Using ‘fit to window’ can cause the images to appear at different scales making it difficult to see if the text is crisp. If your exported image appears to be of lower quality then you have definitely lost some quality. However if your exported image appears to be clear when viewed on its own but blurry in the form, this may be because your preview is scaled. Lowering your export quality will not fix this issue.
I’m with @xzenshellx on trying lossless PNG optimization, but I’d do that comparison first. Otherwise you can spend ages adjusting a perfectly readable file because the website is showing you a lousy thumbnail. Keep the file-size check and the readability check separate, and judge readability from the actual saved file.
PNG compression settings aren’t quite like JPEG quality settings. Increasing the compression on a PNG (so more lossless compression) will mean the encoder has to do more work to compress those pixels but reducing the quality on a JPEG means losing detail in your image. This is an even worse trade off for small labels. You’ll notice when exporting there is a slow saving option which is a much better compromise than having blurry text, however you may not save too much space.
If the form accepts WebP then it’s a different question entirely. We’re all in a situation where we have to choose between JPEG (which will blurry our text) and PNG. Lossless WebP will almost always compress a lot better than a PNG on a screenshot but won’t touch any actual pixel values. You’ll get the same image with less data, just make sure you know what formats are accepted.
@blueeagle6586 is right that cranking PNG compression costs you time, not quality, and the slow save is worth it. But for a screenshot with flat UI colors and crisp text, PNG is often not the most efficient lossless container to begin with. That’s the part I’d test rather than accept.
Where I’d push back is on the edit-the-background idea from @the_stack. Fine in theory, but repainting a wallpaper or a preview pane behind the labels is more effort than it sounds, and it’s easy to leave a halo around the text if there was any blur or shadow. For a quick upload I’d rather crop to just the region that matters. Cropping is honest, fast, and it drops file size hard because you’re literally sending fewer pixels. If the form only needs to see the labels, you don’t need the whole desktop.
The practical order I’d use: confirm the starting file isn’t already a re-saved JPEG, try lossless WebP if allowed, crop anything irrelevant, and only then reach for a quality slider. And like @mystic_router227 said, judge the result at 100 percent on the saved file, not in the form’s preview box. A lot of people burn an afternoon fighting a thumbnail scaler that was never going to show them the truth.
One thing to remember. If the original screenshot is a lossy format and your labels are blurry you won’t gain anything from this. Ideally reshoot. No encoder can recover any detail that wasn’t recorded.
Whether the form requires exact dimensions or just a minimum is still unclear. If the dimensions are fixed, @iron_badger’s cropping suggestion doesn’t meet your requirement, and stretching the crop back would defeat the point of protecting small text. Yes, you can reduce file size without changing width and height, but that doesn’t guarantee you can reach this particular upload limit without damage. I’d treat “fit to target size” as a request to the encoder, not a promise of readable labels. There may simply be no export setting that satisfies all three constraints: unchanged dimensions, unchanged detail, and the form’s size cap.
Two screenshots. One is a spreadsheet with boring grey toolbars and black text on white. The other has the same window with a background image and a gentle shadow below the panel. Both are the same size in pixels and format - but the files are very different in size. Compressing them will affect them in completely different ways. However, many people are giving advice as if it’s only one screenshot.
For the flat one, I’ll actually push back on @retroloop_77’s worry about color reduction. Indexed PNG, dropping to 256 or even fewer colors, is close to free on pure UI text. There’s no subtle shading next to the letters to wreck because the letters sit on a solid fill. That’s exactly the case where a ‘reduce colors’ tool is doing lossless-looking work and your labels stay razor sharp. The shading warning only bites on the second screenshot, the one with the wallpaper and the shadow, where banding will show up fast.
@iron_badger is right about WebP, and I’d put it higher than most people do. Lossless WebP on a flat screenshot often lands well under what PNG manages, pixel-for-pixel identical, no slider involved. The catch is purely whether the form accepts it. Check that before you spend any time, because half the upload forms I’ve hit silently only take JPEG and PNG and will bounce a WebP after you’ve already optimized it.
Where I’d be blunt: chasing the ‘fit to target size’ number is a trap for this specific problem. @vibergirl already said it and I’ll second it harder. A target-size encoder on a text screenshot almost always reaches for JPEG-style lossy behavior to hit the number, and that’s the one thing that kills small labels. If you must use a size-target feature, make sure it’s targeting a lossless format, otherwise you’re just asking it to blur your text politely until the file is small enough.
If none of the above methods work and the original image simply won’t fit into your cap, you can try cropping the image. It’s better to have fewer pixels of the important part than show all of it blurry. When trying out your crop, make sure to set it to 100% rather than using the preview area on the form. The preview will always give you a false impression of sharpness.