ElanoryaImage checks
Checking a PNG for real transparent pixels
The pixel search runs only on a PNG that declares an alpha channel, and it reads a copy downscaled to 64x64 pixels on your own device. When the browser cannot decode the image, the answer is that it cannot say — not that the file is opaque.
Result
Choose an image to check it.
What this does not tell you
Where the answer is computed
The file you pick is read into memory with `arrayBuffer()` and drawn onto a canvas in your browser. Across the six files that make up this surface there is no fetch, XMLHttpRequest, sendBeacon or WebSocket call, so these components do not send the image anywhere to get their answer (apps/web/components/tools/etsy-image-checker.tsx, `const buffer = await file.arrayBuffer();`, read 2026-08-18).
That statement covers the components' own code and nothing wider. The page shell that surrounds them is a separate surface, and it is not something this page can settle.
How the format itself is determined from the opening bytes of the file is a separate mechanism and is not derived here. Whether the app will accept a given photo at all is decided on the device before an upload begins, which the page on accepted files settles.
What the transparency check actually looks at
Three conditions decide whether there is a transparency answer at all, and what shape that answer takes.
- PNG only, and only with a declared alpha channel.
- The pixel search sits behind one gate: `if (facts.format === "png" && facts.alphaChannel) {` in apps/web/components/tools/etsy-image-checker.tsx. A transparent WebP or GIF never reaches it, so silence about transparency on those formats is not a negative answer.
- A 64x64 copy, not the original.
- The scan runs on a downscaled sample — `const sample = 64;` in the same component — chosen deliberately to keep the cost low. Alpha is blended as the copy is made, so a few transparent pixels at full size may not survive into the sample.
- Undecodable means unanswered, not opaque.
- When the alpha channel is declared but the pixel result is undefined, the outcome is an informational note stating that it cannot be said: apps/web/lib/image/evaluate.ts, `} else if (facts.alphaChannel && hasTransparentPixels === undefined) {`. Nothing that could not be verified is reported as a pass.
- A finding is about the sample that was read.
- A verified finding tells you transparent pixels were present in what was scanned. The absence of a finding tells you they were not present in what was scanned, which is a narrower statement than the file being fully opaque.
Two tools, two sentences about one file
The resizer prints a transparency label on its source card as soon as a PNG carries an alpha channel: `{facts.alphaChannel ? ` · ${labels.hasTransparency}` : ""}` in apps/web/components/tools/product-image-resizer.tsx. It is reading the header, and it says so quickly.
The checker will not make that statement without reading pixels. So the same file can produce a transparency label in one place and no transparency finding in the other, and neither tool is wrong — they are answering different questions.
The ceiling that reconciles them is short: a fully opaque RGBA PNG also carries an alpha channel. The label means the channel exists, not that any part of the image is see-through.
Four ways to misread the result
Each of these is a reading that the underlying rule does not support.
Reading the resizer's transparency label as visible transparency.
It is a header fact. An opaque RGBA PNG produces the same label, so wait for the pixel-verified answer before acting on it.
Reading "we cannot say" as "there is no transparency".
That outcome is informational and means the pixels were not verified. Supply a copy the browser can decode and check again.
Reading a clean scan as proof the file is fully opaque.
The scan is a 64x64 sample; the absence of a finding is not proof of opacity. Note it as no finding and inspect the full-size file if the answer matters.
Reading silence on a WebP or GIF as a transparency verdict.
The pixel search never runs on those formats. There is no verdict to interpret, in either direction.
Before you record a transparency answer
Five short confirmations, in the order they change the answer.
- Confirm the file is a PNG — on any other format the pixel search does not run.
- Confirm the answer you are looking at came from pixels, not from a header label.
- If the answer is that it cannot be said, treat the file as unknown and try a copy the browser can decode.
- If there is no finding, write down that nothing appeared in the 64x64 sample, not that the file is opaque.
- Keep the verdict and the destination as two separate decisions; the verdict describes the file.
What this page does not settle
These are outside the surface this page was written from, and were left to their owners.
- What a marketplace does with a transparent upload today. The code applies only its own recorded rule text, and the currency of that text cannot be verified from here.
- How the file format is determined from the opening bytes, and which signatures are recognised — that is a separate mechanism and was left to its own page.
- The format, compression and conversion behaviour of any output file, which is decided elsewhere and was not read.
- What happens in a browser without the imaging support these tools rely on; the code shows only a general error in that case.
- Whether these tools exist in languages other than English, and what any interface label reads in them.
- Any promise about privacy or data-protection compliance. What was observed is narrower: no network call in these components' own code.
Questions
How do I check whether a PNG has a transparent background?
Have the checker read the file. The pixel search runs when the file is a PNG whose header declares an alpha channel, and it scans a copy downscaled to 64x64 pixels on your own device (apps/web/components/tools/etsy-image-checker.tsx, `const sample = 64;`). A verified finding means transparent pixels were present in that sample.
The file has an alpha channel but I cannot see any transparent area. Which is right?
Both, because they are different statements. A fully opaque RGBA PNG carries an alpha channel, so a label derived from the header can be true while no part of the image is see-through. Only the pixel-verified answer speaks about visible transparency.
Why do two tools disagree about the same file?
The resizer prints its transparency label from the alpha channel alone, while the checker declines to state transparency without verifying pixels. The two sentences describe the same file at two different depths.
Does the check upload my file?
These components read the file with `arrayBuffer()` and work on a canvas, and no fetch, XMLHttpRequest, sendBeacon or WebSocket call appears in any of the six files on this surface. That covers the components' own code; the page shell around them is a separate surface and is not settled here.
The result says it cannot say. What should I do with that?
Treat the file as unknown. The alpha channel was declared and the pixels could not be verified, so the outcome is informational — nothing unverified is reported as a pass. Re-check with a copy the browser can decode.