See a 3D print’s G-code layer by layer

What it shows

• The toolpath, layer by layer. A slider steps through the layers; each one is drawn from above with every printed line at the nozzle’s width, coloured by what the slicer said it is (outer wall, inner wall, infill, solid and top infill, bridges, overhangs, support, skirt and brim, wipe tower) and with the layer below in grey. Travel moves, where the nozzle moves without printing, are hidden until you ask for them. Click a feature in the key to hide it.
• All layers in 3D. The whole print as coloured lines you can turn and zoom, built up to the layer the slider is on, so you can watch where a support starts or how a bridge spans a gap.
• The slicer’s facts. Which slicer and version made the file, the printer profile, the print time estimate, filament length in millimetres and weight in grams (worked out from the length if the slicer wrote no weight, with the density used shown), layer count, first layer and normal layer height (and the range when the layer height varies), nozzle size, every nozzle, bed and chamber temperature the file sets, the printed size and position on the bed, and counts of moves, arcs and retractions.
• The thumbnail. The preview pictures PrusaSlicer, OrcaSlicer and BambuStudio embed for the printer’s screen: PNG, JPG and QOI (the format Prusa printers use, decoded here by a small reader written for this site). All sizes are shown, largest first.
• Every setting, searchable. The settings block PrusaSlicer, SuperSlicer, OrcaSlicer and BambuStudio write at the end of the file (often 300 or more lines of ; key = value), Cura’s ;SETTING_3 block, and header lines such as Cura’s ;FLAVOR: and ;TIME:. Type “temp”, “retract” or “speed” to find what you need.
• Binary G-code. A Prusa .bgcode (the default for the MK4, XL, MINI and CORE One since PrusaSlicer 2.7) is unpacked here: its metadata, thumbnails and G-code blocks, with the heatshrink compression and MeatPack encoding undone and every block’s CRC32 checked.

Reading a G-code file

A worked example

A calibration cat sliced in PrusaSlicer 2.9.2 for a Prusa MINI is 635 KB and 28,635 lines. It holds four thumbnails (16×16, 220×124 and 200×240 in QOI, 380×285 in PNG), 174 layers of 0.2 mm, an estimate of 37 minutes 15 seconds and 2,224.99 mm of filament, which the slicer weighs at 6.64 g. Adding up the extrusion moves gives 2,222.5 mm: the 2.5 mm difference is the slicer counting differently around retractions. The print is 28.2 × 28.0 × 34.8 mm, the nozzle is set to 170 °C for bed levelling and then 230 °C and 220 °C, the bed to 60 °C, and 233 of its moves are arcs (G2/G3).

Why the time is the slicer’s

How long a print takes depends on the firmware’s acceleration, jerk or junction deviation and input shaper settings, which the G-code does not fully carry. The slicer simulates them for the printer profile it knows; this page shows that estimate, and does not invent its own.

How layers are found

When the slicer marks layers (;LAYER_CHANGE in PrusaSlicer and OrcaSlicer, ;LAYER: in Cura), those marks are used. Otherwise a new layer starts when printing resumes at a new height, so a Z-hop between islands is not counted as a layer.

Filament weight

Grams are the slicer’s figure when it wrote one. Otherwise the length is turned into volume with the filament diameter and into weight with the density the file states, or 1.75 mm and 1.24 g/cm³ (typical PLA) when it states none; PETG is about 1.27 and ABS about 1.04, so an ABS print weighs about 16% less than this estimate.

Large files

The file is read in 4 MB pieces by a background worker, so the page keeps responding while a 100 MB file loads. The layer view draws every move of the chosen layer. The 3D view merges runs of short moves into single lines once a print passes 400,000 lines (150,000 on a phone) so it stays smooth; it says when it has.

Written for this site

The G-code reader, the QOI decoder and the binary G-code reader are viewhack’s own, written from the G-code conventions of Marlin, Prusa and Klipper firmware, the QOI specification and the libbgcode file specification. The binary reader was checked against the sample files in Prusa’s libbgcode repository: unpacked here, they give the same layers and filament as Prusa’s own text conversion. The 3D view uses three.js (MIT), served from this site.

What this cannot do

• Simulate the print time. Only the slicer’s own estimate (or the first M73 progress line) is shown. A file with no estimate gets none.
• Print. It does not talk to a printer, OctoPrint, PrusaLink, Klipper or a Bambu cloud. It only reads the file.
• Match every firmware exactly. Moves are read the way Marlin, Prusa and Klipper firmware read them (G0/G1, G2/G3 arcs as short straight pieces, G90/G91, M82/M83, G92, G20/G21). Klipper macros such as PRINT_START, firmware retraction (G10/G11, counted but not drawn), mesh levelling, flow and speed overrides are not applied, and arcs in planes other than XY are drawn as if in XY.
• Open a sliced project. A BambuStudio or OrcaSlicer .gcode.3mf is a ZIP: unpack it in the archive viewer and open the plate_1.gcode inside. A 3MF or STL model has no toolpath yet; the 3D model viewer opens those.
• Read every thumbnail flavour. PNG, JPG and QOI thumbnails in the standard ; thumbnail begin blocks are shown; vendor-specific image formats some printers use are listed only if they decode as one of those three.
• Treat CNC work fully. Mill and laser G-code is drawn as moves, but tool radius, spindle and laser power are ignored, and only moves that also push filament (E) count as printed lines.

Other ways to look inside

Slicers

PrusaSlicer and OrcaSlicer have a G-code preview (File, G-code preview, or drag the file in) that also shows speeds, fan and flow, for files they or another slicer made.

Command line

bgcode from Prusa’s libbgcode converts .bgcode to text and back; any text editor opens a .gcode.