Images & photos · Browser Image & Drawing Editor
What sRGB and 8-bit colour mean for editing photos in a browser
· Background
image-editing canvas browser-processing
Browsers edit images in sRGB with eight bits per channel, a sensible default with real consequences for wide-gamut photos and heavy adjustments. This post explains what those two terms mean and where their limits show.
The photo that looks flatter in the editor than on the phone — a concrete symptom of colour spaces disagreeing
A vivid phone photograph can look different after it enters a browser editor, even when nobody has touched a slider. The visible comparison is real, but its cause is not something this repository identifies for every device, browser, display, or embedded profile. The limitations page states that the editor provides no colour management and warns that embedded ICC profiles may not survive a canvas round trip.
Make the observation useful rather than turning it into a promise. Keep the original, open a duplicate, export without adjustment, and compare both files in the viewer that matters for the job. Canvas drawing followed by toBlob creates browser-managed raster output. That test can document one input and one environment; it cannot establish profile preservation, calibrated accuracy, or a universal sRGB destination.
A colour difference can occur, and this editor offers no managed comparison or adjustment
A colour space gives numerical channels a reference: the same red values can describe different displayed colours under different interpretations. That background helps explain why a file can appear vivid in one application and restrained in another. It is not a description of a ToolAcre conversion step. The editor accepts ordinary raster input and does not expose a profile chooser or a colour-space inspection panel.
The practical question is therefore not whether the interface can settle colour science, but whether the exported file is acceptable for its intended audience. Compare the original and download at the same viewing conditions, record the browser and format, and avoid overwriting the source. For a colour-critical workflow, use software with an explicit managed pipeline rather than inferring one from a canvas preview.
The 1996 origin of sRGB — how HP and Microsoft defined a standard around the monitors of the time and why it stuck
sRGB is useful historical and web context, but its history does not become product evidence merely because the word appears in a brief. Nothing in these editor sources establishes a dated standards story, an output profile, or a conversion policy. The supported claim is narrower: the implementation draws decoded image data onto canvas surfaces and later asks the browser to encode a requested image format.
That distinction matters when a reader needs a dependable master file. The editor can be a convenient place to crop, draw, and export a visible result, but it should not be described as converting every source into a known colour space. Preserve the original and label any test export with its format and viewing conditions. A controlled comparison is stronger than a confident but unsupported profile claim.
sRGB history is outside repository evidence; the editor makes no output-profile promise
Eight bits per channel means each red, green, and blue sample has 256 nominal code values, producing roughly 16.7 million RGB combinations before other limits enter the picture. That arithmetic is useful context for gradients and posterisation, yet it does not prove a particular internal or exported colour-management behaviour. The limitations specifically place RAW, HDR, and high-bit-depth editing outside this accepted PNG, JPEG, and WebP path.
Do not smuggle an adjustment feature into the explanation. The implementation does not expose brightness, contrast, curves, or profile conversion controls. A strong edit performed elsewhere may reveal banding in an 8-bit export, while a simple crop here may not create that change, but the repository does not promise a universal result across browser encoders. Inspect the actual download instead of relying on theory alone.
Wide-gamut phones meet an sRGB canvas — what happens to Display P3 colours when they are converted, and why saturated reds and greens change most
A wide-gamut source makes the boundary especially visible because saturated colours have less room to behave predictably when applications interpret or transform them differently. It is tempting to say that a Display P3 photograph simply becomes sRGB on canvas, but these sources do not specify that conversion. The limitations page instead warns that there is no colour management and that embedded ICC profiles may not survive the round trip.
Treat the browser as part of the specimen. Use a duplicate, note the source format, view the image before editing, export once, and compare the downloaded file in the target application. If the result is for publication or print, move the colour-critical step to a managed tool. The editor’s useful promise is visible raster editing, not a guaranteed wide-gamut conversion or sRGB deliverable.
Wide-gamut conversion behaviour is browser-managed and not specified by this code
Try the claim with a sunset containing a bright orange edge, a deep blue sky, and a saturated foreground. Open the original, avoid inventing an adjustment workflow that the editor does not ship, and record how the preview looks. Crop or annotate the duplicate if needed, then export it. The point of the exercise is to compare an observed input and output, not to certify an invisible conversion.
Open the download in the application that will receive it and compare the same regions side by side. Note whether the apparent difference is in the file, the viewer, or the display conditions; without controlled instruments, that attribution may remain uncertain. Keep the source untouched. The limitations and implementation support a cautious browser-path report, not a claim that the file is sRGB-converted or colour-critical.
Worked check: inspect a vivid original and export without claiming an adjustment control
The scope stops before 16-bit retouching, HDR authoring, RAW development, calibrated proofing, and managed print production. Those workflows may require more precise storage, profile handling, display calibration, and export controls than this editor provides. PNG, JPEG, and WebP output through canvas is not evidence that those wider workflows are supported, even when the resulting image opens successfully in a desktop application.
It also stops before any promise about embedded metadata. The limitations page warns that profiles may not survive a canvas round trip, while the implementation does not offer a way to inspect or repair them. Keep the original for archival or colour-critical use, and use the editor for a practical visible edit whose exported pixels you can inspect. That is a useful boundary, not a defect disguised as certainty.
Takeaway: sRGB is a safe destination — how the Browser Image & Drawing Editor produces files that display consistently, and what to keep in mind for wide-gamut originals
The honest takeaway is not that this editor provides a managed colour destination. It does not promise sRGB conversion, colour management, profile retention, or colour-critical consistency. It does provide a browser canvas workflow for opening local raster images, applying the editing tools that are actually present, and exporting a new PNG, JPEG, or WebP file through browser encoding.
For ordinary sharing, inspect the download in its intended destination and keep the original when the colour matters. For demanding reproduction, use a tool that explicitly documents the required profile and conversion path. A vivid preview can start the investigation, but only the tested export, the receiving application, and a controlled workflow can tell you whether this particular result is fit for purpose.