Across every specific size-target guide on this blog, the underlying decision is the same: light, medium or strong. Rather than re-deriving that choice from scratch for every new file, it helps to have one simple framework you can apply consistently, based on just two questions.
The two questions that decide almost every case
- Do I have a specific size target I need to hit? If yes, work toward that target directly, starting light and stepping up only as needed. If no, prioritise quality and use the lightest level that solves your actual problem.
- Will this be viewed on screen only, or will it also be printed? Screen-only content tolerates more compression than anything that might be printed, where softening is more visible, as covered in our guide on why compressed files can look fine on screen but blurry printed.
A simple decision table
- No specific size target, screen only: light compression, purely to trim obvious excess.
- No specific size target, may be printed: very light or no compression at all; prioritise quality since there is no pressing size need.
- Specific tight size target, screen only: start light, increase toward medium or strong as needed to hit the target.
- Specific tight size target, will be printed: compress as little as the target allows, and consider whether resizing dimensions or reducing page count would hit the target with less quality cost than strong compression.
Why starting light and working up beats starting strong and hoping it's fine
It is tempting to jump straight to a strong setting “to be safe” about hitting a size target, but this routinely sacrifices more quality than necessary. Starting light and increasing only as far as actually needed consistently gives a better-looking result for whatever size you end up at, since you stop the moment your target is met rather than defaulting to the most aggressive option available.
When the content type should override the general framework
Some content types warrant a different default regardless of the general framework above — a document with small, dense text (a legal document, fine print) deserves extra caution even for screen-only use, since text legibility degrades faster than photographic content under compression. A simple, flat-colour graphic or icon tolerates strong compression far better than the framework's general caution might suggest. Use the framework as a starting point, then adjust for what you actually know about your specific content.
Applying this to a recurring task so you stop re-deciding each time
If you compress a similar kind of file repeatedly — the same type of scanned form, the same kind of product photo — work out the right level once using this framework, note it down, and reuse that same setting going forward rather than re-evaluating from scratch every time. This is the same principle covered in our guide on why different tools give different results: consistency, once you have found a setting that works, is more valuable than re-optimising every single file individually.
What to do when you are genuinely unsure
If you cannot confidently answer either of the two core questions — you do not know if there is a size limit, or you are not sure if the file might be printed — default to the more cautious choice: assume there might be a limit worth checking for, and assume it might be printed unless you specifically know otherwise. It is easier to compress further later if a size target turns out to matter than to recover quality that was already discarded unnecessarily.
Why this framework works across both images and PDFs
The same two questions apply whether you are compressing a standalone photo or a PDF full of scanned pages, since the underlying trade-off between size and quality is the same mechanism in both cases. This is deliberate: rather than learning a separate mental model for each file type, one consistent framework covers the compression decision across everything on this blog.
Writing your own quick-reference version of this framework
Once you have used this framework a few times, it is worth condensing it into a short personal note — your own typical answers for the kinds of files you deal with most often, rather than working through the full two-question process every single time. Most people find that after the first several applications, a small number of recurring patterns cover the majority of their actual compression decisions, at which point the framework becomes something you apply almost automatically rather than something you have to consciously think through.
Frequently asked questions
Is there ever a case where strong compression is clearly the right first choice?
Yes, when you know the file is screen-only, has a tight size requirement, and is mostly simple or already fairly small content, jumping to a stronger setting can save a step without meaningful risk.
Does this framework apply to compressing an already-compressed file?
Recompressing has different, more limited returns regardless of level, covered in our guide on why recompressing a JPEG doesn't help; this framework is really about the first compression pass from an original file.
Should I always test at the actual size the file will be used?
Yes, this is a good habit regardless of which level you choose, since it is the only reliable way to confirm the level you picked actually looks right in its real context.
Is it worth writing down my usual settings for different file types?
Yes, if you handle similar files repeatedly, a short personal reference saves re-deciding the same question every time.
Does this framework apply to video or audio compression too?
The general principle (size target and viewing context both matter) applies broadly, though this site's specific tools and guides focus on PDFs and images.
What if my file needs to satisfy both a size limit and high print quality, and these conflict?
Consider reducing page count or resizing dimensions rather than relying on stronger compression alone, since these can reduce size without the same quality cost as pushing compression further.
Are the compression tools free either way?
Yes. No sign-up, no watermark, and files are removed from the server automatically about an hour after processing.