Every modern Paint-style color inversion works by replacing each red, green, and blue channel with 255 minus the original byte, leaving the alpha channel untouched. Paint's command is built around exactly that operation, and so is every serious browser clone of it, including Invert Image Colors — both tools follow the rule that output red equals 255 minus input red, output green equals 255 minus input green, and output blue equals 255 minus input blue, applied to every pixel that survives decoding. This simple subtraction produces a photographic negative: black becomes white, white becomes black, red becomes cyan, green becomes magenta, and blue becomes yellow. Because the rule is deterministic, applying it twice always returns the same bytes you started with. A few subtle differences still separate Paint from a careful browser tool — selection behavior, output format, animation handling, metadata, and whether your image ever leaves your machine — and those are worth understanding before you pick a workflow.
What "Invert Colors" Means at the Pixel Level
The word "invert" sounds dramatic, but the operation is one line of arithmetic per channel. For each pixel in the decoded image, the tool computes a new red value as 255 minus the old red value, a new green as 255 minus the old green, and a new blue as 255 minus the old blue. The alpha value, which controls transparency, is copied through unchanged. Because every channel is independent, the same rule scales from a one-pixel swatch up to a multi-megapixel photograph without ever needing to look at neighboring pixels.
A worked example makes the rule concrete. Take a single pixel with the source RGB triplet (128, 64, 200) and full opacity. The output red is 255 − 128 = 127. The output green is 255 − 64 = 191. The output blue is 255 − 200 = 55. The result is (127, 191, 55), a muted olive tone that is the exact RGB complement of the input. Run the same formula a second time on (127, 191, 55) and you recover (128, 64, 200), which is why a double inversion is the standard sanity check for any invert implementation.
When the alpha channel is anything other than 255, the rule still applies to the RGB slots, but the visible color depends on whatever sits behind the pixel. A 50% transparent red on a white page will not look like a 50% transparent cyan after inversion; it will look like a 50% transparent cyan blended with the same white background. This blending is normal and is exactly what Paint produces as well.
Doing It in Microsoft Paint (the classic method)
Paint ships with a one-click invert that is built around the same per-channel rule described above. The workflow is short, but a few details about selection behavior and file format matter for getting the result you actually want.
- Open your image in Microsoft Paint. Use File > Open or drag the file onto the Paint window.
- Decide whether you want to invert the whole canvas or only part of it. With nothing selected, the Invert color command affects every pixel on the canvas. If you only want a region, choose the Select tool, draw a rectangle, or press Ctrl+A to select everything before applying the command.
- Apply the inversion. Click Image > Invert color, or use the keyboard shortcut Ctrl+Shift+I. The selection marquee stays in place; only the pixels underneath change.
- Save the file. Use File > Save to overwrite the original, or File > Save as to choose a new format. JPEG output is lossy, so resaving a JPEG through Paint will degrade it further regardless of whether you invert or not.
Two Paint behaviors are easy to miss. First, free-form and rectangular selections invert only the enclosed pixels, so an irregular outline needs the Free-form selection tool with a closed path. Second, Paint does not preserve EXIF metadata, ICC color profiles, or animation: a multi-frame GIF imported into Paint is flattened to its first frame, and a JPEG loses most of its capture metadata the moment Paint re-encodes it. If any of those details matter, you have a reason to look outside Paint.
When a Browser Tool Beats Paint for This Job
Paint is convenient, but the same per-pixel rule can be applied in a browser tab with no install, no upload, and a lossless PNG output. Resizing an Image in Paint? Try Your Browser Instead covers the broader pattern of moving common Paint jobs into local browser tools, and the inversion case fits the same argument: a browser tool can read the bytes, decode them, run the formula, and hand back a PNG without sending your file to a server.
Privacy is the headline reason to switch. How to Invert Colours on an Image Without Uploading It spells out the difference in plain terms: a local tool keeps every read, decode, transform, and encode inside the current tab, while a typical "free inverter" uploads the original to a remote service. For personal photos, scanned documents, or anything with embedded metadata, the local path is safer by construction.
File handling is the second reason. Paint struggles with very large images and flattens any animated input to its first frame. A browser tool with explicit byte budgets and per-edge pixel limits can give you a clear "file too large" message instead of a stalled canvas, and can preserve alpha through the inversion so a transparent PNG round-trips correctly. The lossless PNG output also avoids the second-generation JPEG degradation that Paint applies when you resave a photo.
Invert an Image in Your Browser Step by Step
The Invert Image Colors tool runs the same 255-minus-channel rule Paint uses, but it does the work locally and returns a still PNG. Three operational steps drive the whole interaction.
- Choose a PNG, JPEG, GIF, or WebP file and wait for byte-container detection, browser decoding, and dimension validation. The tool checks the actual file bytes — not the filename or the supplied MIME — and requires a real browser decode before any pixel work begins.
- Invert the decoded initial frame, then compare the source and complete natural-size PNG previews. Every pixel that the browser exposes through Canvas is transformed as 255 − R, 255 − G, 255 − B with alpha copied unchanged, so transparent pixels keep their transparency and fully opaque pixels keep their shape.
- Confirm dimensions and output byte size, then download the still PNG. The export is always a complete PNG; truncated or lossy fallbacks are not produced, and an output that exceeds the separate PNG byte budget is rejected before a download link is shown.
Selecting a different file mid-run increments the job generation, closes the previous ImageBitmap, and revokes the old preview URLs, so a stale download never leaks into a newer selection. The whole loop is wrapped against React Strict Mode's double-effect cycle and against null toBlob callbacks, which is the practical reason a "Confirm dimensions and download" step is reliable on the first try.
Color Mapping Reference
The table below lists common input colors and their exact RGB complements after one pass of inversion. These are deterministic outputs from the formula, not sampled values, so they hold for any tool that follows the 255-minus-channel rule.
| Input color | RGB in | RGB out |
|---|---|---|
| Black | (0, 0, 0) | (255, 255, 255) |
| White | (255, 255, 255) | (0, 0, 0) |
| Red | (255, 0, 0) | (0, 255, 255) |
| Green | (0, 255, 0) | (255, 0, 255) |
| Blue | (0, 0, 255) | (255, 255, 0) |
| Cyan | (0, 255, 255) | (255, 0, 0) |
| Magenta | (255, 0, 255) | (0, 255, 0) |
| Yellow | (255, 255, 0) | (0, 0, 255) |
| 50% gray | (128, 128, 128) | (127, 127, 127) |
Note the 50% gray row. Because 255 minus 128 is 127 and not 128, the exact center of the gray ramp shifts by one byte after inversion. That asymmetry is harmless for visual work and is a known property of the formula, not a bug.
File Limits, Validation, and What Gets Discarded
Invert Image Colors applies a stack of explicit checks before, during, and after the per-pixel transform. None of them is hidden, and none of them silently resizes, crops, or rescales your image. The hard boundaries are listed below.
| Boundary | Value |
|---|---|
| Reported file size (input) | ≤ 15 MiB |
| Actual ArrayBuffer length (input) | ≤ 15 MiB |
| Output PNG byte budget | ≤ 32 MiB (separate from input) |
| Decoded edge length | ≤ 8,192 pixels per side |
| Decoded pixel area | ≤ 24,000,000 pixels total |
The input and output budgets are deliberately separate, because a PNG re-export of a noisy photograph or a complex illustration is often larger than the JPEG, GIF, or WebP you started with. A file that decodes to within the edge and area limits but expands past the 32 MiB PNG ceiling will be rejected before a download link is published, with a clear error rather than a truncated image. The MDN reference for HTMLCanvasElement.toBlob describes the synchronous export behavior the tool relies on for that check.
Format detection is structural rather than nominal. The tool reads the actual ArrayBuffer and looks for the PNG signature plus IHDR plus terminal IEND, the JPEG SOI plus a following marker plus EOI, the GIF87a or GIF89a header plus logical-screen structure plus trailer, or an exact RIFF byte count plus WEBP marker plus a bounded VP8, VP8L, or VP8X first chunk. The Google documentation for the WebP RIFF container defines that byte layout. Files renamed from SVG, AVIF, HEIC, BMP, TIFF, or PDF fail the structural check even if their extension claims otherwise, and they fail before any Canvas work.
A few properties of the source are deliberately not preserved. EXIF, GPS, ICC color profiles, comments, and other source metadata are not carried into the PNG export. Animated GIF and animated WebP inputs use only the browser-decoded initial frame, so the result is a single still PNG regardless of how many frames or loop iterations the source had. Semi-transparent pixels keep their alpha, but the browser decoder or Canvas may normalize visually hidden RGB before the loop sees it, so a fully transparent region in the output is not necessarily the literal complement of a fully transparent region in the input. If any of those details matter for your file, keep the original alongside the inverted PNG.