Where the preview lives
When your printer shows a little picture of the model next to the file name, that picture is inside the .gcode file itself, written as a run of base64 comment lines:
; thumbnail begin 220x124 12345
; iVBORw0KGgoAAAANSUhEUg…
; thumbnail end
This tool finds those blocks, decodes them, shows you every one it found, and lets you save them individually or all together as a ZIP.
The details it reports
For each block you get the kind the header declared, the format detected from the file's own magic bytes, the pixel size, the base64 character count next to the number the slicer declared, the decoded byte count, and the source line. That last pair matters: the number in a ; thumbnail begin header is the base64 character count, not the decoded size, which is why some extractors report a size mismatch on perfectly good files. This one does not.
Formats
PNG and JPEG blocks are handed back byte-for-byte as the slicer wrote them. QOI — a compact format that newer PrusaSlicer and RepRapFirmware builds use because it decodes fast on a printer's microcontroller — is decoded here and re-encoded as PNG, because no browser can display it natively.
What is handled
PrusaSlicer, SuperSlicer, OrcaSlicer and Bambu Studio blocks, including the _QOI, _JPG and _PNG variants, and Duet files that open a QOI block and close it with a plain ; thumbnail end.
Ultimaker Cura is handled only when the "Create Thumbnail" post-processing script was used. Cura's own preview lives in a .ufp package, which is a ZIP with the image as a separate part — not in the .gcode.
What is not
PrusaSlicer's binary .bgcode container is recognised and named rather than mangled: re-export as plain ASCII G-code to read its preview. The vendor-specific binary BMP headers some FlashForge and Weedo machines prepend are not read either.
Everything runs in your browser. The file never leaves your computer, and neither do the images.
Tiny Online Tools






