Image

Image tools — read the file, or sketch a layout. That is it.

Two indexed jobs: dump what is still in the bytes, and guess colors/bands from a screenshot. Resize, compress, QR, and Base64 in the grid are commodity clones. Launcher densities live on the Android icon generator — that page does not write Adaptive Icon XML.

Decision guide

Path A — What is still in the file

Drop JPEG, PNG, GIF, WebP, or SVG. EXIF/IPTC comes from on-demand exifr (jsDelivr). PNG walks tEXt / tIME / pHYs. If GPS remains, it appears in the JSON — do not paste that into a public ticket. Messengers often already emptied the tags; empty EXIF is normal, not a bug. We do not write a cleaned file.

Path B — A screenshot that is not a design file

The “screenshot to code” page downsamples, quantizes HEX swatches, scans horizontal luminance bands, and emits a header/main/footer scaffold. It will not read your nav labels. Treat the CSS variables as a sketch, then implement against the real design system.

Path C — Icons for an Android or PWA surface

Canvas-resize one square PNG. Place files into mipmap-* yourself. For maskable / adaptive assets, padding in this tool is not a layer-list. PWA icon paths are strings in manifest.json — this hub does not fetch those files.

What we keep on the shelf (and what we do not pretend)

Resizers, compressors, converters, QR/barcode, color extractors, and SVG toys exist on every toolkit farm. Indexed image pages: metadata viewer and screenshot heuristics. The rest of the grid is there if you already landed on DroidXP.

Frequently asked questions

Are images uploaded?

Local tools decode in the tab. The metadata viewer loads exifr from jsDelivr on first JPEG analysis.

Is screenshot-to-code AI?

No. Math on pixels. No server model.

Which page should a reviewer open first?

The Android hub. This hub is adjacent asset work, not a second product line.

Indexed image desks (2)

Read next