Colour inversion is the operation of replacing every red, green, and blue channel value in an image with its complementary byte: output red equals 255 minus input red, output green equals 255 minus input green, and output blue equals 255 minus input blue, with the alpha channel preserved unchanged. Applied to a whole picture, the rule is mechanical and identical for every pixel, so a black pixel becomes white, a white pixel becomes black, a pure red pixel becomes pure cyan, a pure green pixel becomes pure magenta, and a pure blue pixel becomes pure yellow. The transformation does not need any colour-management conversion, gamma linearisation, or perceptual complementary colour model — it is a direct byte operation on the decoded RGBA matrix that the browser exposes through a Canvas element. That simple definition is exactly what the Invert Image Colors tool performs: pick a PNG, JPEG, GIF, or WebP, wait for the file to be validated by its actual bytes and by a real browser decode, and export a still PNG in which every RGB slot has been replaced by 255 minus its original value while alpha stays the same. The whole pipeline — file reading, byte detection, decoding, pixel access, transformation, preview, and PNG export — runs inside the current browser tab, so the source image is never sent to an external server.
What inverting colours actually does to a pixel
Every pixel that the browser decodes into an ImageData buffer carries four byte channels: red, green, blue, and alpha. The inversion rule ignores the meaning of those numbers as a colour and treats them as 0–255 integers. For each pixel, the tool computes the three new colour channels independently:
- output red = 255 − input red
- output green = 255 − input green
- output blue = 255 − input blue
- output alpha = input alpha (unchanged)
Because every channel is inverted in isolation, the result is the photographic negative you would expect from the mathematical definition. A pixel at RGB(120, 50, 200) becomes RGB(135, 205, 55). A pixel at RGB(0, 128, 255) becomes RGB(255, 127, 0). Applying the same rule twice returns the original bytes, because 255 − (255 − x) equals x for any 0–255 value.
It is worth separating this byte-channel rule from two things it is not. It is not a colour-managed conversion, so it does not linearise gamma or model sRGB transfer curves. It is also not film-negative restoration, so it does not remove an orange mask, balance a scanned negative, correct exposure, or perform tonal grading. If you need any of those, a raw photo editor or a colour-managed tool is the right choice.
| Input RGB | Output RGB | What changes visually |
|---|---|---|
| 0, 0, 0 (black) | 255, 255, 255 (white) | Darkest pixel becomes brightest |
| 255, 255, 255 (white) | 0, 0, 0 (black) | Brightest pixel becomes darkest |
| 255, 0, 0 (red) | 0, 255, 255 (cyan) | Pure red swaps to its complement |
| 0, 255, 0 (green) | 255, 0, 255 (magenta) | Pure green swaps to its complement |
| 0, 0, 255 (blue) | 255, 255, 0 (yellow) | Pure blue swaps to its complement |
| 120, 50, 200 | 135, 205, 55 | Each channel flips independently |
File formats accepted and what the validator checks
The tool accepts four container formats: PNG, JPEG, GIF, and WebP. It does not trust the filename extension, the file-picker filter, or the operating-system MIME label, because all three can lie. Instead, the tool inspects the actual ArrayBuffer and applies the same pure structural detector used by the paired Base64 image workflow. If the byte pattern does not match a complete supported container, the file is rejected before any Canvas work starts.
The structural rules are explicit. A PNG must contain the complete 8-byte signature, the first IHDR structure, and a terminal IEND. A JPEG must contain an SOI marker, a following marker, and a terminal EOI. A GIF must start with GIF87a or GIF89a, carry enough logical-screen structure, and end with the trailer byte. A WebP must carry an exact RIFF byte count, the WEBP marker, and a bounded VP8, VP8L, or VP8X first chunk. Truncated magic bytes and renamed arbitrary files fail before Canvas work begins.
After structural detection, the detected MIME is used to build a Blob. That Blob must then decode through createImageBitmap and report real positive dimensions — structural detection does not replace browser decoding. Files outside these four formats — SVG, AVIF, HEIC, BMP, TIFF, PDF, and others — are out of scope even if the filename has been changed to something supported.
How to invert colours on an image
The full workflow has three confirmed phases. Each one needs to complete before the next starts, and re-selecting a file resets every previous result.
- Choose a PNG, JPEG, GIF, or WebP file and wait for byte-container detection, browser decoding through createImageBitmap, and dimension validation. If any of those checks fail, the file is rejected before the tool displays a preview.
- Invert the decoded initial frame. The tool reads complete ImageData from a Canvas drawn at natural dimensions, mutates every pixel as 255 − R, 255 − G, 255 − B with unchanged alpha, and puts the full matrix back. The source preview and the inverted preview are then shown side by side at natural size for direct comparison.
- Confirm dimensions and output byte size, then download the still PNG. The export is encoded from the full natural-size image, never cropped or resampled, and is always a complete PNG regardless of which input format was used.
Selecting another file immediately increments a job generation, closes the prior ImageBitmap, revokes both the source and the output ObjectURLs, clears any old errors and results, and resets busy state. Late file reads, bitmap decodes, and toBlob callbacks from a previous job cannot publish into the newer selection. Cleanup stays safe even through React Strict Mode effect setup and cleanup cycles.
The Canvas export step uses the browser's native PNG encoder via the toBlob method, as documented in the MDN HTMLCanvasElement.toBlob reference. A null Blob, an invalid size, or a Blob above the exact 32 MiB output budget fails before a result URL is published.
File size and dimension limits
The tool enforces three independent limits before it begins work, and they all need to be satisfied at once. Compressed inputs can expand into large pixel buffers, and long narrow images can stay below an area limit while still exceeding practical Canvas dimensions, so the limits are checked separately rather than derived from one another.
| Limit | Value | Why it exists |
|---|---|---|
| Input file size | 15 MiB | Reported File size is checked before reading, then the actual ArrayBuffer length is checked again after reading. |
| Maximum edge | 8,192 pixels per side | A browser Canvas has practical size limits even when memory would allow a larger buffer. |
| Maximum area | 24,000,000 pixels | Long narrow images can stay below an edge limit while still exceeding usable Canvas dimensions. |
| Output PNG size | 32 MiB | The output budget is separate from the input because PNG is uncompressed and a noisy source can produce a larger result. |
Exact boundaries are accepted. One byte, one edge pixel, or one area pixel beyond the limit is rejected. Files below these limits but renamed from an unsupported container still fail the structural check, so the limits are not a substitute for the byte detector. Nothing is silently resized, cropped, sampled, or partially processed.
What the output PNG keeps and drops
The output is always a complete, full-resolution PNG and nothing else. Animation, metadata, and source-file side data are dropped, so the output is not a faithful byte-for-byte copy of the input.
- Decoded RGB values are replaced with the byte-level complement.
- Alpha is preserved unchanged for every pixel.
- Natural pixel dimensions are kept — no resize, crop, or resample is ever applied.
- The file format is always PNG, regardless of input format.
- EXIF, GPS, ICC profiles, comments, and other metadata are not preserved by Canvas export.
- Animated GIF and animated WebP inputs become one still PNG. Later frames, timing, loops, palettes, and disposal behaviour are not carried over.
- Hidden RGB under zero alpha is not guaranteed. The tool inverts whatever Canvas actually supplies, but a browser decoder or Canvas may normalise visually hidden RGB before getImageData returns it, so the tool cannot recover source bytes that never reach ImageData.
If you keep the source file alongside the output, you have everything you started with plus the inverted still PNG. Because PNG conversion can change metadata, animation, and colour-management behaviour even though the decoded RGBA transformation itself is exact, the original is the file to fall back on when any of those properties matter.
When colour inversion is not the right tool
Byte-channel inversion is a specific visual effect, and there are several tasks it cannot do. It does not linearise gamma, so an sRGB photograph and a linear image with the same RGB bytes will not look the same after inversion. It does not model perceptual complementary colours, so designers who want a softer or warmer inversion will need a colour-managed editor. It does not remove an orange film mask, balance a scanned negative, correct exposure, or perform tonal grading — those operations need raw-photo or colour-managed tools.
It is also not the right choice if you need to keep animation, embedded ICC profiles, EXIF metadata, GPS data, or other source-file side data in the output. For those cases, keep the original file and run the inversion in a tool that can write a copy in the original format with the original metadata intact.
For other local pixel-level effects, Lizely also provides Image Flipper for mirroring, Pixelate Image for censoring parts of an image, and Blur Image for selective softening, all of which run inside the same browser pipeline so the file is never uploaded. Successful decoding is not malware analysis, content moderation, authorship verification, or proof that an image is safe or truthful — pick a tool that matches the actual job.