Guide
One sentence carries this page: the cover is not the leak — the remainder is.
Everywhere else on this site, a redaction fails because something was recoverable from inside the covered region: a blur that was too weak, a pixel grid that preserved too much, a box drawn as an object that sat above the pixels rather than replacing them. This failure works the other way round. The covered region is a dead end and the attacker never goes near it. They read what you left, and they calculate.
That difference matters practically, because it means none of the usual defences help. Choosing Black Box over Blur does not help. Downloading a lossless PNG does not help. Verifying that the pixels were really overwritten does not help. All of those confirm that the covered region contains nothing, which was never in dispute. The number is somewhere else in the frame, spelled out in a different form.
Four shapes of arithmetic that hand the number back
1. One unknown in a visible sum. The simplest and by far the most common. A column of line items with a total underneath. You cover one line and leave the rest, plus the total. The covered figure is the total minus everything visible. If an expense report shows six items summing to a total of 1,240 and five of them read 300, 180, 95, 220 and 145, the covered one is 300. Not approximately 300. Exactly 300. The cover has told the reader where to look and the total has told them what is there.
2. A visible difference. The statement pattern, and the one people miss most often because there is no total anywhere. A bank or card statement usually prints a running balance next to every line. Cover a transaction amount and the balance column still shows what the balance was before it and after it. The transaction is the difference between those two figures. Covering the closing balance achieves nothing here, because the equation is repeated on every row: each adjacent pair of balances reveals the line between them. This is the specific reason a statement is harder to redact selectively than it looks, and it is worth reading alongside the field-by-field walkthrough in how to redact a bank statement.
3. A ratio, rate or percentage. Any figure stated twice in two units is stated once too often. If a summary line says a category accounts for 18% of spending and the overall spending figure is visible, the category figure is the product of the two. If an invoice covers the unit price but shows quantity and line total, the unit price is the line total divided by the quantity. Tax lines are the same trick with a known multiplier: subtotal, tax and total are three numbers with two degrees of freedom, so any one of them can be recovered from the other two, and the tax rate is often recoverable as well.
4. A count and an average. A dashboard that shows an average order value and an order count publishes the total. If it also shows all but one of the individual orders, it publishes that one too. Averages feel like summaries rather than data, which is why they get left visible, but an average multiplied by a count is a sum, and a sum with one gap is a lookup.
In every one of these cases, the value you covered is the only unknown in a relationship whose other terms are legible. That is the condition to look for, and it is a property of the document, not of the effect you applied.
Near-misses are usually near enough
Sometimes the remainder does not pin the number exactly. It gives a range instead. It is tempting to treat that as a pass, and it usually is not.
Rounding is the common case. If the visible figures are shown to the nearest whole unit, the arithmetic recovers your covered value to within a unit or two rather than to the cent. If someone wanted to know whether a payment was closer to 200 or to 2,000, a range of a couple of units answers the question completely. The useful way to think about a range is to ask what decision the reader would make differently at either end of it. If the answer is nothing, the range is a disclosure.
Ordering constrains things too. A table sorted by value places a covered row between its visible neighbours. If the rows above and below read 4,100 and 3,950, the covered row is between them, and you have published a figure accurate to a few per cent without any addition at all.
Bounds can be enough on their own. Cover a salary in a payroll screenshot but leave the department total and the other salaries, and even if a couple of other cells are also covered, each covered cell is now bounded: it cannot exceed the residual after the visible ones are subtracted, and it cannot be negative. Two covered cells sharing one residual give you a pair of figures that must add to a known amount, which is a much smaller space than either cell had alone.
And multiple covers can be worse than one. Covering two cells in a table that shows both row totals and a column total may leave a system with two unknowns and two independent equations, which solves cleanly. Adding a second cover intuitively feels like adding protection; in a doubly-totalled table it can supply the second equation that makes the first cover solvable.
The non-numeric version of the same trap
The underlying problem is not arithmetic specifically. It is that the visible part of an image constrains the hidden part. Numbers make it exact; other structures make it narrow.
Sorted lists. An alphabetical list of names with one covered puts the hidden name between its neighbours. Between "Harrison" and "Hayes" is not a large space.
Charts and gauges. A bar can be measured against its axis whether or not its data label is covered. Covering the label on a bar chart while leaving the bar, the axis and the gridlines is close to covering nothing. The same applies to pie slices, progress bars, gauges and sparklines. If the graphic is drawn to scale, the graphic is the value.
Stated counts. Interface text that says how many items exist — "11 results", "4 unread", "showing 1–20 of 63" — tells the reader how many rows were there before you covered some, and sometimes that count is the sensitive part.
Percentages that must total 100. Structurally identical to a visible sum, with the total pre-printed by convention rather than on the page.
Layout. A covered value still occupies its cell, so the column width, alignment and digit grouping around it tell you its magnitude. A right-aligned currency column makes the number of digits in a covered figure visible from the position of the cover alone.
A four-question solve test
Run this on the finished image, before you send it. It takes under a minute and it is the whole method.
1. Cover up your own covers and read what is left. Look at the exported image as though you had never seen the original. Deliberately ignore what you know is underneath. The reader has only the remainder, so judge only the remainder.
2. List every relationship still visible. Totals, subtotals, running balances, tax lines, averages, counts, percentages, per-unit rates, chart axes, sort order, anything printed twice. Write them down if the image is complicated — the relationships are easy to miss one at a time and obvious as a list.
3. Try to solve for each covered value. Actually do the subtraction. Not "could someone probably work this out" but "here is the number". This is the step people skip, and it is the only one that gives a real answer.
4. If you got a number, or a range you would not want published, cover more — or send something else. There are only two honest outcomes, and the second one is legitimate.
What to do when the arithmetic wins
Once you know a covered figure is recoverable, the options are limited and it helps to see them ranked rather than to keep drawing boxes.
Cover the relationship, not just the value. The minimum fix is to remove enough of the visible terms that no equation closes. Cover the total as well as the line. Cover the whole balance column, not the closing figure. Cover the average alongside the count. This is often the right answer for a small table, and it is frequently more of the image than people expect.
Cover the block. For a table with totals in two directions, cover the numeric region as a single rectangle and keep only the headings. Trying to preserve a scatter of individual cells in a doubly-totalled table is how solvable systems get built by accident.
Re-capture instead of redacting. Usually the best option and the most overlooked. Go back to the application, filter, collapse, hide columns or switch to a view that does not contain the sensitive figures, and screenshot that. A view that never had the number in it cannot be solved for the number, and you get a clean image rather than a heavily blacked-out one. This is also the only route to substitution, because replacing a value with a placeholder has to happen upstream — the editor on this page cannot write anything onto an image.
Round or band at the source. If the recipient needs the shape of the data and not the figures, change the figures upstream to bands or rounded values before capturing. Do this in the source document, and tell the recipient you have done it.
Send a different artefact. If what the recipient actually needs is one fact, send that fact in a sentence. A screenshot is a dense bundle of information that happens to contain the answer, and the reason this failure is so common is that people send the bundle when they meant to send the answer.
What the editor above does and does not do here
This section is read from this page's own code, because the boundary matters for this particular problem.
It destroys regions; it cannot alter values. Three modes and three shapes. Black Box fills the region with a flat near-black. Blur rebuilds it from a copy reduced by a factor of ten and scaled back up. Pixelate averages it into blocks of at least six pixels, each taking its colour from the block's centre pixel. Every one of these replaces what was inside the region you drew, which is why the covered pixels are genuinely gone — and also why none of it addresses arithmetic. There is no text tool, no drawing tool and no way to type a character onto the image, so substituting a figure is not something the tool can do at any setting.
It has no idea what the image says. There is no text recognition and no content analysis anywhere in the code. It cannot find numbers, cannot see that a column has a total, and cannot warn you that the region you just covered is recoverable from the one three rows down. The solve test is yours to run; the tool only executes the covers.
The lasso is useful for irregular numeric regions. Because the fix here is usually "cover more of a shape that is not a neat rectangle" — an L of line items plus a total, a balance column with a gap — the freehand lasso is worth using. It fills the closed path you draw, so you can take out an awkward region in one pass instead of stacking rectangles and leaving slivers between them.
Undo is per-cover and Clear starts over. Each applied cover is snapshotted, so Undo steps back one at a time while you experiment with how much to remove. Clear redraws the original image, which is the fastest way to restart when you decide the block approach was right after all.
Very small drags are silently ignored. A rectangle under about four image pixels, or an oval under six, does nothing and says nothing. Single digits and narrow currency cells are exactly the kind of target where this bites, so check each cover landed rather than assuming it did.
The preview scrolls and the export does not. The canvas is displayed scaled to fit a panel capped at seventy per cent of the window height, with its own scrollbar, while edits run at true pixel size. Long tables are precisely the case where a total sits far below the rows — possibly off-screen while you work. Scroll the entire image before exporting, because the total you never saw is the one that solves your cover.
Download writes a flat PNG at the source pixel dimensions. The file is exported from the canvas as an image named hideshot- followed by a timestamp, with no layers, no objects and no text content. Everything happens in your browser; nothing is uploaded anywhere, and the page stores nothing between sessions — no localStorage, no sessionStorage, no IndexedDB, no account.
Common mistakes and misconceptions
"The box is solid, so the number is gone." The box being solid is necessary and not sufficient. Solidity settles what is inside the region and says nothing about what the rest of the page implies about it.
Covering a line item and leaving the total. The single most common version of this failure, and the easiest to fix.
Thinking a statement is safe because it has no total. A running balance is a total on every row.
Covering the closing balance and considering the job done. That removes one of thirty equations.
Leaving the tax line visible. Subtotal, tax and total are two facts written three ways.
Treating averages and percentages as summaries rather than data. An average times a count is a sum, and a percentage of a visible base is a value.
Covering the label on a chart but not the bar. The bar is drawn to scale against a visible axis.
Assuming more covers means more safety. In a table with totals in two directions, a second cover can supply the equation that makes the first one solvable.
Accepting a recovered range as a pass. Ask what the reader would do differently at each end of the range. Usually nothing, which means the range is the answer.
Forgetting that sort order is information. A covered row in a sorted table is bracketed by its neighbours before anyone does any arithmetic.
Redacting a screenshot when a sentence would have done. Most of these failures happen because an image was sent where one fact was needed.
Not scrolling to the bottom of a long table before exporting. The fitted preview hides the row that matters, and the export contains it.
Checking the redaction while still knowing the original. You cannot judge what the remainder implies while your eye keeps filling in the covered cell. Read it as a stranger, or the test does not work.