When Your Redacted File Is Too Big to Send

Every other page on this site is about a judgement call: which region is sensitive, how much of a number can stay visible, whether a blur is strong enough for what is underneath it. This page starts after all of that is settled and correct. The covers are in the right places, the image is finished, and the thing standing between you and a sent message is a portal that says the file is too large, or a form that will only take a JPG, or an email client that refuses the attachment.

That is a different kind of problem, and it has a specific cause that catches people out precisely because they did nothing wrong. Redacting an image here does not edit your file in place and hand it back. It decodes the image, paints over the regions you selected, and writes out a brand new file — a lossless PNG, at the source image’s exact pixel dimensions. For a screenshot that is unremarkable. For a photograph that arrived as a compact JPEG, the new file can easily be several times the size of the one you opened, which is a genuinely surprising result when the only thing you did was cover something up.

The instinct at that point is to redact less, or to reach for the first “compress image online” result and hope for the best. Neither is necessary. The size change has a mechanical explanation, the order in which you shrink and convert matters more than the tools you use, and — the part worth internalising — nothing you do to the exported file afterwards can weaken the redaction, because the covered pixels stopped existing before the file was written. If you want the format question in its own right, see does blurring work the same on png vs jpg?.

Drop your image here

Or click to browse · Paste with Ctrl+V also works

PNG · JPG · WebP · GIF

How It Works

Open

Drop your image in or paste from clipboard.

Pick Mode

Black Box, Blur, or Pixelate.

Select Areas

Rectangle, oval, or freehand lasso — then hide what you selected.

Download

Hit Download PNG. Done.

SquooshNeed to shrink your image after editing? Squoosh is a free browser-based image compressor with no upload required.

Visit Squoosh →

Guide

One sentence carries this page: the download is a re-encode, not a copy of your file — which is why a photo that came in as a small JPEG can leave as a large PNG, and why the correct response is a conversion step rather than a weaker redaction.

Why a correctly redacted file gets bigger

The editor on this page draws your image onto a canvas at its exact pixel dimensions, paints your covers directly into those pixels, and — when you press Download PNG — writes the canvas out with a single lossless PNG encode. Two consequences follow from that, and between them they account for nearly every size surprise.

The first is that the output is always a PNG, whatever you put in. PNG is lossless: it reproduces every pixel exactly, with no quality setting to turn down. The second is that the output keeps the source’s pixel dimensions, because there is no resize, no crop and no whole-image operation anywhere in this editor — a twelve-megapixel phone photo comes back out as a twelve-megapixel PNG.

Now put that next to what a JPEG actually is. A camera JPEG is small because it has already discarded detail, permanently, in the places your eye is least likely to notice. When those surviving pixels are decoded and re-encoded losslessly, the encoder has to describe all of them faithfully — including the fine sensor noise and the blocky edges that the JPEG compression itself introduced, which happens to be exactly the sort of high-frequency texture that lossless compression handles worst. The predictable result is a file several times larger than the one you opened. Nothing has been added to it. There is no second copy of the original tucked inside, no editing history and no layer stack; the export is a flat picture and that is all it is.

Screenshots behave differently, and it is worth knowing which case you are in before you start worrying. A screenshot is usually already a PNG made of large flat areas of interface colour, so re-encoding it lands in the same neighbourhood as the original file, and frequently below it. If you are redacting screenshots, you will rarely meet a size limit at all. If you are redacting photographs, you should expect to.

Which redactions shrink the file, and which do not

Here is a counter-intuitive fact that happens to point in a useful direction: covering more of the image usually makes the exported file smaller, not larger. Black Box fills the selected region with a single flat colour, and long runs of identical pixels are the cheapest thing you can put in a PNG. Pixelate replaces each block with one sampled colour, which is also flat and also cheap. Blur downsamples the region heavily before scaling it back up, which destroys fine texture and leaves smooth gradients — cheaper to store than what was there, though not as cheap as a flat fill.

So the mode you choose has a real effect on output size, and it pushes in the same direction as the safety advice everywhere else on this site: the strongest cover is also the most compressible one. If you are close to a limit and weighing a blur against a black box over the same region, the black box wins twice. What it will not usually do is rescue a large photograph on its own, because the bytes live in the part of the frame you did not cover. Do not talk yourself into covering extra area you have no reason to cover — it is a marginal saving, and an unexplained black rectangle in the middle of an image invites questions you then have to answer.

The order of operations that keeps the redaction intact

When the export really is too big, the sequence matters more than the particular tool you reach for. Work in this order.

1. Redact at full size, before anything else. The editor applies its operations at the image’s true pixel dimensions even though the on-screen view is scaled to fit the window, so full size is where your selections are most precise. Resist the temptation to shrink first and cover afterwards: a downscaled copy still contains every sensitive value until you paint over it, and small text does not reliably become unreadable just because the image got smaller.

2. Export, and treat that file as the master from here on. Once the PNG is on disk, the covered pixels are gone from it. Everything after this point operates on a file that no longer contains the sensitive content, which is what makes the rest of the process safe.

3. Shrink the export, never the original. Going back to the untouched original to make a smaller version means redoing the redaction on a second file, and now two differently redacted images of the same scene exist. That is its own hazard, and it is avoidable simply by always working forwards from the export.

4. Change format before you change dimensions. Re-encoding the flattened PNG as a JPEG typically buys you a large reduction for a cost paid mostly in texture. Reducing the pixel dimensions buys you a reduction paid in legibility, and legibility is usually the entire reason you are sending the image. Spend the cheap currency first, and only shrink dimensions if the limit still is not met.

5. Prefer a converter that works in your browser. Handing a file to an arbitrary online compressor means giving a third party a copy of it. The redaction limits what that copy contains, which is a real mitigation — but it is still a copy you had no need to create. The card further up this page links Squoosh, which does this step without requiring an upload, and any offline image viewer with an export option will do the job too.

6. Open the final file and look at it. Not the thumbnail in a file manager and not the preview pane in your mail client, both of which are downscaled and forgiving. Open the actual file at full size, confirm the covers are still solid and opaque, and confirm that everything you needed the recipient to read is still readable. Then attach that file, and check that the one you attached is the one you just inspected.

What compression can and cannot do to a redaction

It cannot undo one. This is worth being precise about, because it is the anxiety that makes people avoid the conversion step and send a file that bounces instead. The covers are painted destructively into the canvas before the PNG is written: there is no mask, no adjustment layer and no retained original inside the export. Lossy compression and downscaling both work by throwing information away. Neither possesses any mechanism for reconstructing detail that is not present in the file, and no amount of re-saving will make covered pixels reappear.

What compression can do is change how the redaction looks, in three ways worth anticipating. A hard-edged black box saved as a low quality JPEG picks up ringing along its border — a faint halo of noise where the encoder struggles with the sharp transition — which can be mistaken for a semi-transparent overlay by a cautious recipient. It is cosmetic, not a leak, but it costs you a round of questions; the same family of edge artefacts is covered in more depth in how to redact a photo without leaving editing artifacts. Aggressive downscaling softens the boundary of a partial redaction, so if you deliberately left the last four digits of something visible, it can become ambiguous which characters were covered and which were merely blurry. And the failure people actually hit is the opposite of the one they fear: they shrink until the file fits, and the reference number, the date or the single line that justified sending the image is no longer legible.

When the limit is pixels, not bytes

Not every limit is measured in megabytes. Some forms cap the longest edge or the total pixel count, some cap both, and some accept only one file type regardless of size. Read the constraint printed next to the file picker before you start, because satisfying it on the first attempt is much faster than discovering it after three exports.

If the constraint is dimensional, know that the editor here will not help with it: there is no resize control, and the export always matches the source’s dimensions exactly. That step belongs after the export, in whatever tool you use to convert. If the constraint is a file type, the same applies — every download from this page is a PNG, and converting it is a separate step that, for all the reasons above, is entirely safe to perform on the redacted file.

What the editor above does and does not do

The editor is region-based and nothing more: three modes — Black Box, Blur and Pixelate — across three selection shapes, rectangle, oval and freehand lasso. Every operation replaces the pixels inside a region you drew. There is no crop, no resize, no rotate and no whole-image adjustment of any kind, and no quality slider, so the size of the export is decided by the content of your image rather than by a setting you can change here.

Download PNG writes the current canvas out as hideshot-<timestamp>.png, re-encoded from scratch, which means no tags from your source file are carried into it. Undo restores the canvas to the state before your last cover, Clear restores the untouched image, and you can download as many times as you like during a session. All of it runs in your browser: the image is decoded, edited and exported on your own machine, and nothing is sent anywhere. That also means there is no server-side size limit to hit on this page — the only practical ceiling is what your own device can hold in memory, and the only limit that matters is the one printed on the form you are filling in.

Common mistakes and misconceptions

“The file got bigger, so something was added to it.” Nothing was. A larger file after a lossless re-encode is the expected outcome of the format change, not evidence that an original, a history or any hidden data came along for the ride.

“Compressing it might reveal what is underneath.” Compression only removes information. There is nothing underneath to reveal, because the covering happened to the pixels themselves before the file existed.

“I will just rename it from .png to .jpg.” The extension is a label, not the encoding. Anything that inspects the actual bytes — which most upload validators do — will reject the file or fail to render it, and you will have spent a submission attempt finding that out.

“I will screenshot the redacted image to make it smaller.” It works, crudely, but you lose resolution by an amount that depends on your display scaling, and screenshots have a habit of capturing the window around the picture: a file path in a title bar, the name of the folder, the other tabs you had open. Redacting a file and then leaking its filename through a screenshot of the viewer is a real way to lose.

“I will zip it.” Compressing an already-compressed image saves close to nothing, and plenty of portals reject archives outright or treat them as suspicious attachments.

“It is easier to send the original and ask them to ignore the private part.” A file size limit is an inconvenience. Sending an unredacted original is a disclosure, and the request not to look at it has no force whatsoever once the file is in someone else’s inbox, backup and search index.

“I will redact less so it fits.” This is the only mistake on the list that trades a real protection for a technical convenience, and it is backwards in both directions — covering more generally makes the file smaller, not larger.

A Bigger File Is Not a Weaker Redaction

Redaction guidance is almost entirely about judgement - what to cover, how much to leave, whether a blur is strong enough. The problem on this page appears after all of that is finished and correct. The image is properly covered, and the portal rejects it, or the form insists on a JPG, or the attachment bounces. The cause is mechanical and easy to miss: the editor does not modify your file and hand it back, it decodes the image, paints the covers into the pixels, and writes an entirely new lossless PNG at the source image’s exact dimensions. A screenshot survives that unchanged in size or smaller. A camera JPEG, which was small precisely because it had already thrown detail away, comes back several times larger, because a lossless encoder now has to describe every surviving pixel including the compression noise the JPEG itself created. Nothing was added to the file, and no original is hiding inside it.

The order of the fix matters more than the tool. Redact at full size first, because the editor works at the image’s true pixel dimensions and because a downscaled copy still contains every sensitive value until you paint over it - shrinking is not redacting, and small text does not reliably become unreadable just because the picture got smaller. Export, and treat that flattened PNG as the master. Then convert format before reducing dimensions: re-encoding as JPEG costs you texture, while shrinking costs you legibility, and legibility is usually the whole reason the image is being sent. Prefer a converter that does the work in your browser rather than one that wants the file handed over, since the redaction limits what that copy would contain but does not make it a copy worth creating. Finally open the result at full size, not as a thumbnail or a mail-client preview, and confirm both that the covers are still opaque and that what must stay readable still is.

Everything after the export is safe to do, which is the point worth keeping. The covers are destructive - the pixels are replaced before the file is written, with no layer, mask or retained original in the export - so compression and resizing, which work only by discarding information, have no way to bring anything back. What they can change is appearance: a hard-edged black box saved at low JPEG quality picks up edge ringing that can look like a translucent overlay, and heavy downscaling blurs the boundary of a deliberate partial redaction. Both are cosmetic. The genuine risk runs the other way, in shrinking so far that the reference number or the date you needed the recipient to read is gone. And one instinct is simply backwards: covering more area generally makes the exported file smaller, because flat fills compress better than the detail they replaced, so a size limit is never a reason to redact less.

Frequently asked questions

Why is my redacted image so much larger than the photo I started with?

Because the export is a re-encode rather than a copy, and it is always a PNG. The editor draws your image onto a canvas at its exact pixel dimensions and writes that canvas out losslessly when you press Download PNG, so nothing about the original file's compression survives the round trip. A JPEG from a phone camera is small because it has already discarded detail permanently; describing the surviving pixels losslessly - including the fine noise and the blocky edges that the JPEG compression itself introduced, which is exactly the kind of texture lossless compression handles worst - routinely takes several times the room the JPEG did. Nothing has been added to the image, and no copy of the original is stored inside it. Screenshots behave differently: a screenshot is usually already a PNG of flat interface colours, so the redacted export tends to land close to the original or below it, because the covers you drew compress better than the content they replaced.

Will compressing or resizing the redacted file undo the redaction?

No. The redaction is destructive at the pixel level - the covered pixels are replaced on the canvas before the file is ever written, so there is no layer, no mask and no hidden original in the exported file for anything to recover. Lossy compression and downscaling both work by discarding information; neither has any mechanism for restoring detail that is not in the file. What they can change is how the redaction looks. Saving a hard-edged black box as a low quality JPEG produces ringing along the edge that can read as a translucent smear rather than a solid fill, which sometimes makes a recipient ask whether the cover is really opaque. Heavy downscaling softens the boundary of a partial redaction, so it gets harder to tell which characters were covered and which were left. The more common problem runs the other way: shrink far enough and the content you needed to stay readable - a reference number, a date, the one line on a receipt that the whole message is about - stops being readable, which defeats the point of sending the image.

The form only accepts JPG, or rejects my file as too large. What is the safe way to convert it?

Convert the export, never the original, and do it after redacting rather than before. Because the covered pixels are already gone from the exported PNG, anything you do to that file afterwards - converting it to JPEG, lowering quality, reducing dimensions - cannot bring them back, so the conversion step carries no redaction risk at all. Two practical notes. Renaming the file from .png to .jpg converts nothing; the extension is a label, and a system that inspects the actual bytes will either reject the file or fail to display it. And prefer a converter that does the work in your browser over one that asks you to hand the file over, since that is an extra copy you did not need to make - the card further up this page links Squoosh for exactly this step. If you have the choice, reduce quality before you reduce dimensions: quality loss mostly costs you texture, while shrinking the image costs you the ability to read small text, which is usually the thing the recipient actually needs.

Should I shrink the image before redacting, to save a step?

Redact first. Working at full size is more accurate, because the editor applies every operation at the image's true pixel dimensions even though the view on screen is scaled down to fit the window, and a small cover placed by eye on a downscaled preview is easy to misplace by a few pixels at full resolution. The more important reason is that downscaling is not a redaction. Text that looks illegible in a smaller copy has not been removed, only made harder to read, and how hard depends on the viewer's screen, their zoom level and whatever sharpening the next application applies on the way in. A cover replaces the pixels; a resize only rearranges them. So do the covering at full size, export the flattened PNG, and then shrink that export as far as the limit requires.