Does anyone else get almost no size reduction when compressing PNG screenshots with a free online tool? I’m putting together a bug report with 17 screenshots, mostly settings windows and error messages. I uploaded one PNG, downloaded the compressed file, and checked its size. It was barely smaller than the original.
I expected more of a drop without changing the image dimensions. The small text needs to stay readable, so resizing isn’t useful for this report.
The thing people get wrong about shrinking an image is treating the file-size number as the whole job. Getting under an upload limit doesn’t tell me whether the picture still meets the required dimensions, keeps its transparency, or looks acceptable. The advice I’d keep from this tool’s description is to check those separately, rather than assuming a smaller download is automatically a usable one.
Before changing anything, I’d keep the original and work with a smaller copy for uploading. That gives me something to compare against instead of judging the compressed version from memory. I’m not looking for the lowest possible number of kilobytes if getting there makes the picture unsuitable.
The format warning deserves attention before anyone starts adjusting settings. The description says a PNG can come out as JPEG. I can’t confirm which circumstances trigger that conversion, so I wouldn’t assume the output keeps the input format. For an ordinary photo, that might be fine. For a logo that needs a transparent background, I’d check the downloaded format before calling the job finished.
I’d also judge the result at the size people will actually view it. Faces, fine edges, and small lettering are the details I’d inspect, not just the amount of space saved. There aren’t any comparison results supplied that would let me promise a particular level of quality. That part still needs a visual check.
I’d read the receiving site’s requirements before choosing a compression level. File size and pixel dimensions are separate conditions. Meeting one doesn’t establish that the other is right, which is why I wouldn’t start by repeatedly lowering quality without checking the rest.
The described size-limit control is straightforward: choose “Fit a size limit” and enter 200 when the allowance is 200 KB. The same approach is offered for 100 KB or 50 KB. Those are useful instructions, but they aren’t evidence that every possible image will reach the requested size with acceptable detail. I’d still inspect the downloaded file.
For a strict 1 MB allowance, I’d leave a little room below the limit rather than aim exactly at it. The source doesn’t specify how much headroom to leave, so I’m not going to invent a precise setting.
If the result is still too large, the maximum-width setting is the next thing I’d consider. Reducing unnecessary resolution can make more sense than applying increasingly harsh compression to a huge picture. I’d only do that after checking any required dimensions, though. A smaller file isn’t helpful if I’ve made it too narrow for the form.
The option being suggested is this free image compressor. Its description lists JPG, PNG, and WEBP inputs, with a choice between a quality setting and a target file size, followed by downloading the result. That sounds suited to the everyday oversized-image problem, but I haven’t independently verified its behavior across those formats.
It’s also described as completely free, with no signup and no watermark. I can report those claims, not present them as things I personally tested. The same distinction matters for the statement that processing happens entirely in the browser rather than uploading photos to a server. I couldn’t independently verify that processing claim from the supplied information.
Batch processing is listed too. I’d test a detailed picture before applying the same approach to a whole group, then check whether the result preserves what matters. A shared setting is convenient, but the description doesn’t establish that it will suit every picture equally well.
My verdict: I’d try it for a routine upload-size problem before considering a paid photo editor. I wouldn’t treat its claims or a smaller file-size number as proof of success. I’d keep the original, confirm the output’s size, dimensions, and format, and only upload the copy once it passes a visual check.
However, this depends on whether it does lossless compression. If your PNG is very optimised you may not get much of a reduction in size. Whilst I do agree that making the image readable is important, I would not aim for a specific file size as it may cause issues with small text in the screenshots. You might not want to change tools or pay for one just for minor reductions in file size.
With a full screen capture there is plenty of room to crop. If you are capturing an error dialogue then there won’t be too much to crop. Whilst a free compressor would help with this, if there isn’t much to compress then it is not a problem. For this bug report I would suggest that we crop the unneeded parts of the desktop to reduce the size. We will still want to keep the window title, the full error message and any settings required to fully understand this. This will also help reduce any unnecessary clutter. Just make sure you do not crop out any context that would be needed to replicate the bug.
Public demos can be reduced using a free compression tool. However, if it’s an error from work then make sure that your information is private. If there isn’t much of a reduction then don’t bother uploading the same images of the bug to multiple sites.
The crop option can help however there may be some sensitive information within the error. Before using another tool look for any account names, internal emails, file paths or login details. Save the original image privately and create another image with the sensitive information removed.
Do not remove all technical information, ensure that you keep the error code and settings. You can use a free tool but do not upload the original report to another service as there wasn’t much of a reduction.
I’m about to get ahead of myself. If you have a screenshot-only bug report then you’ll end up having to do some manual typing of the error message you need to search for. So before going any further, split out the text needed for diagnosis.
Yes, a free online tool can compress PNG screenshots, but almost no reduction isn’t automatically a tool failure. PNG already uses compression. A lossless optimizer has to find a more compact way to store the same pixels, and there may not be much left to save. Paying for a compressor doesn’t change that constraint. I agree with @phantom_dragon689 on that, though I’d question whether every screenshot needs to remain an image at all.
Including actual error messages in code blocks, or including a plain text log file (if supported) would be best. Screenshots can be used to show things that cannot be shown with text such as which option was chosen, where the dialog box was shown or if a control was not present. Only having one screenshot showing the issue and describing how the problem was triggered by different actions can be more effective.
This isn’t saying you shouldn’t include evidence. Just keep your original files and include individual screenshots if there are any visual differences. However, by reducing the amount of duplicate information, you can reduce the file size of what you upload. It also means the investigator has something they can copy, search and quote.
If you don’t mind changing the colours of your PNG, you can also reduce the file size by reducing the range of colours in the image. This is a completely different process to reducing the size of an image. There are free tools you can use to do this, however you won’t know whether it will be reducing the colour range or compressing your image as there isn’t a specific ‘compress’ button.
The lossless explanation from @phantom_dragon689 is right, though I wouldn’t take a tiny reduction as proof that the screenshot can’t get much smaller. Palette reduction can help with interface screenshots by replacing lots of subtly different colors with fewer colors. The caveat is that the file can still be a PNG even though some image information has been discarded. Keeping the extension doesn’t guarantee an unchanged image.
In cases where you are optimizing settings windows and text issues, this can be acceptable. However, if you are dealing with a bug relating to colors being wrong, light outlines or rendering issues then you should avoid reducing your colors. You want to keep those subtle differences, and by using an optimizer you will gain very little but your attachment size will be smaller and hide the issue you are trying to capture.
Stop feeding the same screenshot through a second compressor hoping the number moves. If the first pass barely changed anything, a different free tool is going to hit the same wall, because they mostly lean on the same lossless libraries under the hood. That’s the piece @phantom_dragon689 got right and people keep skipping past.
Where the actual savings hide on UI screenshots is the bit depth. Most screenshot tools dump out a full 24 or 32 bit PNG even when the image is a settings window with maybe thirty distinct colors. Dropping that to an indexed palette is where files fall off a cliff, and it’s the same thing @hyperscript_86 described, just worth naming the reason. A flat dialog box with text survives that fine. Anything with gradients, antialiased shadows, or a color rendering bug does not, so match it to what the screenshot is proving.
My blunt take: don’t overthink 17 settings screenshots. Crop them tight like @vectorbyte5017node said, let the compressor do one pass, and if a few still won’t shrink, just upload them as is. Nobody triaging a bug report cares that one attachment is slightly chunky. Spending twenty minutes chasing kilobytes on an error dialog is effort the report doesn’t need.
