Inverting a picture’s colors is pure arithmetic — every channel becomes 255 minus its value — and done losslessly it is perfect: we inverted a 3000×4000 photo twice through a browser canvas and got 0 of 12,000,000 pixels back different. The file you download is a different story. Every browser tool decodes your picture, inverts it, and re-encodes on export. At JPG quality 90 that re-encode moves 3,435,793 of the 12,000,000 pixels (28.6%) more than 2 levels away from the exact inversion, with a worst case of 47 levels — measured. Two of the nine tool pages on the first results page promise “without losing any quality”; for a JPG download that is not what the file says.
Three traps decide whether your file survives the button. A naive four-channel invert flips the transparency state of 95% of a test image’s pixels — a logo on a transparent background comes back as a white slab. A 16-bit photo leaves a browser tool with 8 bits (65,536 levels in, 256 out). And an animated GIF comes back as a single still frame in a browser, because a canvas holds one frame at a time.
Inverting a color means one operation per channel: the new value is 255 minus the old one. White (255,255,255) becomes black (0,0,0). A mid-gray of 128 becomes 127. Nothing is averaged, nothing is invented — the same subtraction for every pixel, which is why the inverted picture looks like a photographic negative: light areas land in the dark range and vice versa.
Two consequences fall straight out of the arithmetic, and both are checkable on any picture:
| Color (R,G,B) | Exact complement (255−R, 255−G, 255−B) | Name |
|---|---|---|
| (255, 0, 0) | (0, 255, 255) | red → cyan |
| (0, 255, 0) | (255, 0, 255) | green → magenta |
| (0, 0, 255) | (255, 255, 0) | blue → yellow |
| (255, 165, 0) | (0, 90, 255) | orange → azure |
| (255, 255, 255) | (0, 0, 0) | white → black |
Computed with the page’s own formula on the values shown; no rounding involved. Tool pages describe this loosely — “white becomes black, orange becomes blue” and “blue becomes orange” both appear on the first results page. The exact complement of pure blue is yellow; orange’s exact complement is an azure that reads as blue. Close enough for marketing, wrong enough to surprise you when you are matching a brand color.
The exact complement table the tool pages do not print. “Blue becomes orange” is loose language — the arithmetic says yellow.
Here is where “invert” stops being arithmetic and becomes a file operation. We loaded the 3000×4000 test photo into a browser canvas, inverted the pixels in place, and exported two ways. Each export was then compared against the exact inversion (255 minus every channel of the decoded source), counting pixels that differ by more than 2 levels in any channel, out of all 12,000,000.
| Export after one invert | Pixels differing from the exact inversion | File size |
|---|---|---|
| PNG (lossless) | 0 of 12,000,000 (0%) | 14,762,743 bytes (4.89× the source) |
| JPG, quality 90 | 3,435,793 (28.632%), worst pixel off by 47 levels | 2,150,386 bytes |
| Source file, for scale | — | 3,019,770 bytes |
Protocol: source decoded in Chrome, drawn to a canvas, inverted per channel with getImageData/putImageData, exported via canvas.toBlob(). The PNG was compared against the locally computed exact inversion at tolerance 0. The JPG row uses tolerance 2 per channel. A second, independent local encoder produced the same drifted-pixel count — the drift is the encode, not the browser.
The round trip tells the same story from the other side. Invert → export PNG → reload → invert again: 0 of 12,000,000 pixels differ from the original. Invert → export JPG → reload → invert again: the same 28.632% of pixels now sit beyond tolerance. One encode is the entire cost; the second pass adds nothing measurable. A tool that inverts your picture and hands back a JPG has already spent that budget, whether or not it mentions it.
Two of the nine pages on the first results page advertise inversion “without losing any quality”. For a PNG download that is close to true — the inversion itself is lossless and PNG stores the result exactly. For a JPG download the claim fails by 3.4 million pixels. The honest phrasing would be: inverting is lossless; exporting is not.
And there is no lossless route for a JPG invert, unlike a quarter turn or a mirror. Those can be done by rearranging whole 8×8 blocks inside the compressed data — the lossless transform documented for the standard JPEG tool, which our rotate guide covers. Inversion changes every decoded value, so there is nothing to rearrange; every JPG invert decodes the picture and encodes a new one.
The inversion is exact in every row. Only the PNG row still contains it.
A PNG can carry a fourth channel — alpha — that says how transparent each pixel is. Inversion is defined on the three color channels. What a tool does with alpha is where PNGs break, and none of the nine pages on the results page explains the choice. We built an 800×600 test image with 216,000 opaque pixels, 24,000 semi-transparent pixels (alpha 128) and 240,000 fully transparent pixels, then ran the three routes a tool can take.
| Route | What it does | Measured result |
|---|---|---|
| A — correct | Invert R, G, B; leave alpha untouched | All transparency states preserved (240,000 / 216,000 / 24,000 unchanged); the opaque area’s mean color came back (186.60, 91.94, 149.58) — exactly 255 minus the original (68.40, 163.06, 105.42) |
| B — naive | Invert all four channels in one loop | 456,000 of 480,000 pixels (95%) changed transparency state; the transparent area came back as opaque white (its RGB was 0,0,0), and 216,000 opaque pixels became fully transparent |
| C — flatten first | Composite onto a white background, then invert | Zero transparent pixels left; 240,000 pixels of solid black where the transparency used to be |
Protocol: the test PNG was drawn to a canvas and the inversion applied to the raw pixel array, one route per run, exported as PNG and inspected locally. Route A matches what scripting tutorials recommend when they warn about this trap: split the alpha off, invert the three color channels, merge back.
One of the nine tool pages offers a “preserve transparency” checkbox; the table above is what that checkbox is for, and what happens without it. A logo on a transparent background run through route B comes back as a white slab on an opaque background — the shape is intact and the file is useless for its job. Route C is what a tool does when it flattens the preview before inverting; the transparent area turns solid black. If your picture has any transparency, look at the preview before you download.
The same test image through the three routes. Only one of them is still the file you uploaded.
PNG can store 16 bits per channel — 65,536 levels instead of 256. Scans and renders use the extra depth for smooth gradients. A browser canvas does not: it decodes every image to 8 bits per channel, full stop. We built a 1024×1024 16-bit grayscale PNG ramp containing all 65,536 distinct levels, pushed it through the same canvas-invert-export path, and counted.
| Stage | Distinct levels | Notes |
|---|---|---|
| 16-bit source file | 65,536 | every level present, max value 65,535 |
| What the canvas handed back after inverting | 256 | 8-bit export; every group of 256 source levels collapsed into one output level |
| Exact inversion kept offline (65,535 − v) | 65,536 | all levels survive when nothing downsamples |
Protocol: ramp written as a 16-bit PNG, loaded into the canvas, inverted, exported as PNG; levels counted from the files themselves. Compared against the exact 8-bit truncation of the true inversion, 0 of 1,048,576 pixels deviated — the loss is pure level collapse, not noise. The deviation in 16-bit terms is up to 255 steps per pixel.
The visible result on a real 16-bit file is banding: gradients that stepped smoothly through 65,536 levels now step through 256. Tool pages that advertise “high-quality formats” are talking about the container (PNG is lossless), not the depth. If your file is a 16-bit scan or render, invert it offline where 65,535 minus the value keeps every level; the warning in the scripting literature is blunt — use 255 on 16-bit data and the result comes back all black.
An inverted photo reads as wrong because two things happened at once. Every pixel’s brightness complemented — the test photo’s channel means moved from (65.33, 98.63, 115.64) to (189.68, 156.37, 139.36), exactly 255 minus the original, so a dim picture becomes a bright one — and every colored pixel rotated its hue by 180°. Skin, sky and foliage land in ranges no camera produces. That is the negative look, and it is the point when you want a poster or an effect.
One tool page offers “grayscale first for a classic film-negative look”. Measured: converting to grayscale and then inverting differs from inverting and then converting on 829 of 12,000,000 pixels (0.007%), maximum 1 level — the two orders are the same operation, because the luminance weights sum to 1. The option changes the look (no hue rotation, since grays have no hue), not the arithmetic.
Inverting only the brightness channel while keeping hue is a different picture entirely: measured mean hue shift 5.09° against 180.0° for a full invert. It reads as a fill-light effect rather than a negative. If a tool’s “invert” is not the one you meant, this is usually why.
One tool page suggests inversion as a quick dark-mode readability check. Contrast is not invariant under inversion, and the direction depends on the pair. Using the standard contrast formula — ratio = (L1 + 0.05) / (L2 + 0.05), with each luminance computed from the sRGB channels by the spec’s linearization — we got:
| Text on background | Contrast ratio before | After inverting both |
|---|---|---|
| black on white | 21.00 | 21.00 (unchanged — the symmetric case) |
| black on 50% gray | 5.32 | 4.00 (worse) |
| white on 50% gray | 3.95 | 5.24 (better) |
| black on 75% gray | 11.42 | 10.37 (worse) |
| navy on white | 16.56 | 16.68 (better) |
Inputs are the exact channel values shown; the formula and its linearization constants are from the accessibility spec, not our invention. Inversion can raise or lower contrast — it is a preview trick, not a compliance check.
A scanned colour negative is not a picture with the colors subtracted. The film carries an orange mask, and inverting the scan without removing it leaves a severe colour cast — this is documented across the film-processing workflow rather than measured by us: dedicated editor modules and open-source converters exist for exactly this job, and their documented pipelines sample the white balance of the light source, remove the mask, and model the paper curve before and after the inversion. Tutorials for the mainstream editors walk through the same steps by hand. If what you scanned is a negative, expect to do more than press one button — a plain online inverter will give you the cast, not the photo.
We ran the 6-frame 900×1200 test GIF (24,462 bytes) through the canvas-invert path. The export is a perfect single-frame still — 28,753 bytes as PNG, exactly 1 frame counted from the file. A canvas holds one frame at a time, so the other five never make the trip; our rotate guide hits the same wall from the rotation side. The server-side tools on the results page advertise per-frame processing with animation timing and transparency preserved, and that is a genuine difference — the price is that your file leaves your machine and sits in their queue. If your file moves, choose deliberately: browser tool for privacy and a still, server tool for the animation.
The whole test ran on one Windows machine with a desktop Chrome and local scripts. Five inputs: a 3000×4000 JPG (3,019,770 bytes), a 6-frame 900×1200 GIF (24,462 bytes), a 1024×1024 16-bit PNG ramp, an 800×600 RGBA test image, and the exact channel values printed in the contrast table. Every number in the tables came out of those files: pixel counts from full-image comparisons with stated tolerances, byte sizes read from disk, level and frame counts read from the files themselves.
What we did not test, and will not claim: the output quality of any third-party tool, since only the tools’ own pages describe them; the film-negative pipeline itself — the orange-mask workflow is documented by the tools built for it, not run by us; other browsers and phones, whose canvases may downsample differently; and any picture other than the test photo, whose exact drift percentages will differ. The direction of every result — exact math, lossless inversion, re-encode cost, alpha sensitivity, 8-bit ceiling — is the transferable part; the exact percentages are not.
Yes — every picture with colors can be inverted, because the operation is one subtraction per channel: the new value is 255 minus the old. A browser tool does it without uploading the file, and in PNG the result is exact: we measured 0 of 12,000,000 pixels changed across a double round trip. The catch is the export — if the tool hands you a JPG, the file was re-encoded on the way out, and 28.6% of the pixels sit more than 2 levels away from the exact inversion at quality 90.
If you mean a film negative you scanned, a plain invert button gives you the wrong colors. Colour negative film carries an orange mask, and the documented film workflow removes that mask — sampling the light source’s white balance, correcting the film’s response, modeling the paper curve — around the inversion rather than just inverting. Dedicated editor modules and open-source converters exist for exactly this; the inversion is one step inside that pipeline, not the whole job. If you mean a digital negative look, that is the plain inversion this page measures.
“Reverse” usually means mirroring — swapping left and right — which is a different operation from inverting colors. If you took the picture and want the mirrored version, our flip and mirror guide covers it; if you want the negative look, invert is the button on this page. The two are often confused because both appear under “reverse” in menus.
Plenty, and they split into two kinds. Browser tools invert inside the page — the file never leaves your machine, which you can verify by turning off your network and watching the preview still update — but they return 8-bit files and single frames from animations. Server-side tools accept more formats and process every frame of an animation, at the price of an upload and a queue. Pick by what your file is, not by the button count.
The inversion itself is lossless — it is a subtraction, and a PNG round trip returns every pixel exactly. The export is where quality moves: at JPG quality 90 we measured 3,435,793 of 12,000,000 pixels (28.632%) drifting more than 2 levels from the exact inversion, worst case 47 levels, with one encode accounting for the whole cost. Pages promising “without losing any quality” are right about the math and quiet about the encode. Export PNG if the file matters.
Depends entirely on the tool, and this is the trap. Done correctly — inverting the three color channels and leaving alpha alone — every transparency state survives, which we verified on a test image with 240,000 transparent, 216,000 opaque and 24,000 semi-transparent pixels. Done naively — inverting all four channels in one loop — 95% of the pixels swap transparency state and the transparent area comes back as an opaque white slab. A tool that flattens onto a background first fills the transparent area with solid black. Look at the preview before you download.