Batch convert PNG to JPG

Last updated: August 29, 2026

Why is this screenshot folder so heavy?

Screenshots default to PNG on both major operating systems. Apple's own documentation confirms Mac screenshots save as .png files by default, and Windows behaves the same way; a Microsoft support thread confirms PNG is the Snipping Tool's default, with JPG only available by manually changing it each time. Neither operating system defaults to JPG for a reason: PNG doesn't lose any detail, which matters for text-heavy UI captures, at the direct cost of a much larger file.

A single screenshot at 2 to 5MB doesn't feel like a problem. A folder of forty does: a documentation project, a bug report thread, a set of UI mockups exported one at a time, and suddenly a folder that should be a quick email attachment is hundreds of megabytes.

Screen resolution compounds this over time, too. A screenshot taken on a 4K or Retina display carries roughly four times the pixels of the same crop at 1080p, and PNG's lossless compression scales with pixel count rather than shrinking to compensate, so the same documentation workflow produces noticeably heavier files today than it did on lower-resolution hardware a few years ago. The folder isn't larger because more was captured; it's larger because every screenshot in it carries more pixels than it used to.

Apple has started chipping away at this from the other direction: on recent Mac models running macOS Tahoe 26 and later, the built-in Screenshot app offers an HDR capture mode that saves as HEIF instead of PNG. That's a narrow case, HDR capture on newer hardware, rather than the default, so most screenshot folders are still overwhelmingly PNG, but it's a sign the operating systems themselves recognize PNG's size cost even for screen captures.

What actually shrinks when PNG becomes JPG

PNG's compression is lossless, meaning the exact original pixel data can always be reconstructed; it just packs that data as efficiently as possible without discarding any of it. JPG works the opposite way: the JPEG standard is built around discarding detail human vision barely notices, smoothing subtle color gradients in ways that save enormous amounts of space on photographic content. Applied to a screenshot instead of a photo, that same trade-off still holds, flat UI colors and sharp edges compress even more aggressively than photos do, which is exactly why the size drop from PNG to JPG is so much larger for screenshots than for typical photos.

There's a second reason screenshots specifically shrink so much on conversion: a typical UI screenshot mixes large flat regions with fine, high-contrast detail everywhere text and icons meet a background, anti-aliased edges, thin borders, small glyphs repeated hundreds of times across a page. PNG has to preserve every one of those pixels exactly, no matter how imperceptible a tiny difference at an edge would be to a human looking at the screen. JPG is free to smooth over exactly that kind of imperceptible detail, which is precisely the part of a UI screenshot, rather than a typical photo, that tends to make up a disproportionate share of the file.

Upload portals with a per-file size cap

Plenty of destinations cap file size well below what a screenshot folder can produce. CloudConvert's own free tier caps a single file at 1GB, and that's a generous limit by comparison; many job-application portals, support ticket systems and documentation platforms cap individual uploads far lower, sometimes just a few megabytes per file. A single uncompressed screenshot can bump into a limit like that on its own; a batch of them guarantees it, and the failure mode is often silent, a stalled upload progress bar or a generic error, rather than a message that names the file size as the actual problem.

The pattern shows up most in workflows built around submitting evidence rather than sharing images casually: a bug report system that wants five screenshots attached to one ticket, a support form capped per-attachment rather than per-submission, a documentation platform that silently resizes or rejects anything past its own internal limit. None of these portals are unusual or badly built; PNG screenshots are simply heavier than most upload limits were sized around.

When PNG should stay PNG

Converting isn't always the right move. A screenshot that's mostly dense text, a terminal session, a spreadsheet, a code editor, can show visible fuzzing around character edges once JPG's compression touches it, especially at default quality. If a screenshot needs to stay perfectly crisp, either push the quality setting up toward 95-100%, which shrinks the visible difference at the cost of some file-size savings, or use PNG compression instead, which keeps the format losslessly intact and just optimizes how efficiently it's packed.

A mixed folder, some screenshots that are mostly photos or UI mockups, others that are dense text, doesn't have to go through as one batch at one setting. Running the text-heavy files through a size-targeted compression pass instead of a straight JPG conversion keeps them under a specific upload limit without the same visible fuzzing a blanket quality setting would produce.

It's worth checking a batch at 100% quality before assuming JPG won't work at all, too. A lot of the visible fuzzing people associate with JPG comes from aggressive, small-file-focused quality settings, not from JPG's compression itself being incapable of holding text. At the top of the quality range, the file-size savings over PNG shrink, but they don't disappear, and text usually looks close to the original. The trade-off is worth judging on the actual screenshot rather than assumed in advance.

Converting the whole folder here

Drop the folder in, and every PNG decodes and re-encodes to JPG at your chosen quality, entirely in your browser. Nothing uploads, so there's no per-file size cap to run into and no daily count to track, a batch of 3 screenshots and a batch of 300 both just run. The same engine handles HEIC batches and WebP batchesthe same way, if the next folder that needs shrinking isn't PNG.

One difference from converting photos: PNG screenshots generally don't carry EXIF metadata the way camera photos do, since a screenshot is a capture of a screen rather than something a camera sensor recorded, so there's no camera model, GPS location or capture settings to worry about stripping before sharing a batch. What does carry over is the filename and, where the source screenshot tool embeds one, a capture timestamp; both survive the conversion unchanged.

Common questions