G-code Goes Binary With Proposed New Format

For decades, G-code has been the plain-text messenger between digital design and physical motion. It tells 3D printers where to move, CNC machines where to cut, and laser engravers where to politely vaporize material. It is simple, readable, and old enough to have earned a comfortable chair in the workshop. But now, thanks to increasingly complex 3D prints and modern networked machines, G-code has run into a very modern problem: it can get huge.

That is why the proposed binary G-code format, commonly seen as .bgcode, has become such an interesting development. Introduced through Prusa’s ecosystem and supported in PrusaSlicer, binary G-code aims to keep the meaning of traditional ASCII G-code while making files smaller, faster to handle, and easier for embedded hardware to process. In other words, the same dance instructions for the printer, but packed into a suitcase that does not require three people and a forklift.

What Is G-code, Really?

G-code is the language used by many computer-controlled machines, including CNC mills, routers, lathes, 3D printers, and laser cutters. A typical G-code file is made of lines, often called blocks, that contain commands and arguments. For example, a command like G1 X50 Y20 E3 F1500 tells a 3D printer to make a controlled move to a position while extruding filament at a defined feed rate.

The beauty of G-code is that humans can read it. A maker can open a file in a text editor, scan the start commands, adjust a temperature, insert a pause, or troubleshoot a strange movement. That readability is one reason G-code has survived for so long. It is not glamorous, but it is dependable. It is the shop-floor equivalent of a clipboard with coffee stains: not pretty, but it gets work done.

The downside is that plain text is not very compact. Modern slicers generate thousands or millions of repeated movement commands, especially for detailed 3D prints. Add metadata, thumbnails, temperature commands, mesh information, comments, and printer-specific instructions, and a print file can balloon dramatically. For a single desktop hobbyist, that may only be mildly annoying. For print farms, remote uploads, slower network connections, and printers with limited embedded resources, file size matters.

Why G-code File Size Became a Bigger Problem

Older 3D prints were often simple. A file might contain a few perimeter moves, some infill, and enough temperature commands to keep the hot end behaving. Today’s slicers are far more sophisticated. They may generate pressure advance instructions, input-shaping-friendly moves, high-resolution curves, multi-material tool changes, object cancellation data, thumbnails, and detailed metadata for print previews.

All of that information is useful, but it adds weight. A complex model with tiny curves can produce a long chain of short G1 movements. Each line repeats similar letters, spaces, decimals, and comments. The machine does not need those characters to look pretty; it only needs the values and command structure. Binary G-code takes advantage of that reality by storing the same practical information in a more efficient form.

Meet .bgcode: Binary G-code for Modern Printers

The proposed binary G-code format associated with Prusa is designed as an optional replacement for traditional ASCII G-code. It is not meant to erase the old format overnight. Instead, it offers a compact, structured alternative for printers and software that support it.

The open-source libbgcode project describes several improvements over legacy G-code. These include a block structure that separates metadata from G-code, faster navigation through files, encoding and compression for smaller file sizes, checksums for data validity, and extensibility through custom blocks. That last point is especially interesting because it means future systems could add features such as signatures, verification data, richer previews, or production metadata without cramming everything into plain-text comments.

Think of it like moving from a messy folder of handwritten notes to a labeled filing cabinet. The information is still there, but it is organized in a way that software can access more quickly and reliably.

How Binary G-code Works Without Losing the Original Meaning

One of the key promises of binary G-code is that it preserves the meaning of the original file. A standard .gcode file can be converted into .bgcode, then converted back again when manual editing is needed. That matters because makers and technicians do not want a magical black box that eats their print files and burps out mystery bytes.

The conversion tools in libbgcode support different settings for compression and encoding. Metadata blocks and G-code blocks can be handled separately. Options include no compression, Deflate, and Heatshrink compression, while G-code encoding can use MeatPack-style techniques. The format can also use CRC32 checksums, which help detect corrupted data before a machine tries to print from a bad file.

This is not just “zip the file and hope the printer figures it out.” Desktop computers can decompress almost anything without breaking a sweat, but printer firmware often runs on limited hardware. A format intended for embedded systems has to be efficient in memory and CPU use. That is where block-based design matters: the printer or supporting software can process manageable chunks instead of needing to unpack a giant archive all at once.

PrusaSlicer Support and Firmware Requirements

PrusaSlicer added support for binary G-code in the 2.7.0 generation. The software can export .bgcode, load and preview it, and convert files between ASCII G-code and binary G-code through the File menu. For compatible printer profiles, binary G-code support can be enabled automatically, though users can disable it in the settings.

Firmware support is the other half of the puzzle. A printer cannot print a binary file just because the slicer can create one. Prusa documentation states that Original Prusa MINI, MK4, and XL family printers support binary G-code starting from firmware 5.1.0. Users with older firmware or unsupported machines may need to export traditional ASCII .gcode instead.

This detail has caused some predictable workshop confusion. A user updates the slicer, exports a file, places it on a drive, and the printer looks at it like a cat looking at a cucumber. The fix is usually straightforward: update the firmware if the printer supports the format, or disable binary G-code export and return to standard text-based G-code.

The Main Benefits of Binary G-code

1. Smaller Print Files

Prusa’s documentation reports an average file-size reduction of about 70 percent when using binary G-code. The exact savings depend on the model, slicer settings, metadata, thumbnails, and how repetitive the toolpath is. Still, the reduction can be significant, especially for complex prints full of short movements.

2. Faster Uploads and Transfers

Smaller files move faster. That matters when sending prints over Wi-Fi, uploading to printer storage, managing files through cloud services, or running a small print farm. A single large file may not be painful, but dozens of them can turn into a digital traffic jam.

3. Better Structure for Metadata

Traditional G-code often stores metadata as comments. That works, but it is not elegant. Binary G-code can separate file metadata, printer metadata, slicer metadata, and actual motion commands into distinct blocks. This makes it easier for software to find the information it needs without scanning the entire file like a detective in a noir film.

4. Data Integrity Checks

Checksums help confirm that file blocks have not been corrupted. In manufacturing, even small errors can waste material, time, and patience. A failed print is bad enough; a failed print caused by a silent file problem is the kind of gremlin nobody invited.

5. Room for Future Features

The format’s extensible design leaves space for additional blocks. That could be useful for business environments, signed files, authentication, production tracking, or richer previews. It is not hard to imagine print farms wanting better file metadata as additive manufacturing becomes more organized and less “I named the file final_final_v7_reallyfinal.gcode.”

The Catch: Compatibility Is Still the Big Question

Binary G-code is promising, but it is not universal. Traditional G-code works almost everywhere because it is simple text. Binary G-code requires software and firmware support. That means every slicer, host application, printer firmware, file viewer, and workflow tool has to understand what it is looking at.

OctoPrint is a good example. Because OctoPrint traditionally streams standard text G-code to printers, .bgcode can create compatibility issues. A BGCode plugin exists for OctoPrint that allows upload and conversion of binary files, but the plugin’s own documentation notes that disabling the format in slicer profiles may be the better solution for many OctoPrint users. In that workflow, binary G-code may shrink the uploaded file, only for the host to convert it back into ASCII before streaming it to the printer.

That does not make the format bad. It simply means adoption will be uneven. Newer Prusa printers benefit first because the slicer, firmware, and ecosystem are aligned. Broader CNC and 3D printing adoption will depend on whether other firmware projects, slicers, printer manufacturers, and host platforms see enough value to implement it.

Binary G-code vs. Regular Compression

A common reaction is: “Why not just zip the G-code?” It is a fair question. Standard compression can reduce text files very effectively, and G-code is full of repeated patterns. However, zip-style compression is not always ideal for embedded devices. A printer may need to preview, validate, stream, or resume a file without decompressing the whole thing into memory.

Binary G-code is more than a compressed archive. It is a structured format. It can store different sections differently, apply encoding where useful, keep metadata accessible, and support checksums. That makes it more practical for machines with limited resources than simply handing them a compressed blob and saying, “Good luck, little controller board.”

What This Means for 3D Printing

For 3D printing, binary G-code is a practical modernization. The motion commands still describe the same physical actions, but the storage format is better suited to large files, network workflows, and metadata-heavy slicer output. As printers become more connected and feature-rich, the file format needs to do more than carry coordinates.

For the average hobbyist printing a benchy once a month, binary G-code may not feel revolutionary. For a user managing multiple printers, sending files through network tools, storing hundreds of sliced jobs, or working with complex high-detail models, smaller and better-structured files can be a real convenience.

What This Means for CNC Machines

The CNC world is likely to move more slowly. Traditional G-code is deeply embedded in machine shops, controllers, CAM systems, post-processors, and operator habits. CNC users also tend to value transparency and predictable machine behavior. A machinist may not love the idea of a binary file that cannot be opened directly in a text editor before running on expensive stock.

Still, the idea has merit. CNC programs can also become large, especially for detailed 3D toolpaths, high-speed machining, engraving, and surface finishing. A structured binary format could eventually help with verification, metadata, job tracking, and transfer efficiency. But adoption would require strong standards, reliable conversion tools, and plenty of trust. Machine shops do not enjoy surprises, unless the surprise is “the job finished early and nothing caught fire.”

Manual Editing Is Not Dead

One concern about binary G-code is that users lose the ability to hand-edit files. In practice, the workflow is different rather than impossible. If a user needs to edit the file, they can convert .bgcode back to ASCII .gcode, make changes, and convert it again.

That extra step may bother power users who frequently tweak start scripts, temperatures, pauses, or custom commands. For them, plain-text G-code remains more convenient. But for users who rarely touch the raw file, binary export can happen quietly in the background. The slicer handles the packing, and the printer handles the unpacking.

A Simple Example: Why Repetition Matters

Imagine a detailed miniature with curved armor, tiny surface texture, and thousands of short perimeter moves. The slicer outputs line after line of nearly identical commands:

To a human, that is readable. To a storage system, it is repetitive. The letters, spaces, decimal points, and feed rates appear again and again. Binary encoding and compression can reduce that redundancy while preserving the motion data. Multiply that by hundreds of thousands of lines, and the file-size savings become obvious.

Should You Use Binary G-code Today?

If you use a supported Prusa printer with current firmware and PrusaSlicer, binary G-code is worth trying. It can reduce file size and improve transfer convenience, especially if you use Prusa Connect or store many jobs. If you run OctoPrint, Klipper-based workflows, older firmware, or non-Prusa machines, check compatibility first. When in doubt, export regular .gcode. It may be bulkier, but it remains the universal language of “please move the nozzle over there.”

The safest approach is practical: test with a small file, confirm that the printer recognizes it, verify that previews and host tools behave correctly, and keep ASCII export available. Binary G-code should make your workflow smoother, not turn your printer into a guessing game with a heated nozzle.

Experience Notes: What Binary G-code Feels Like in Real Workshop Use

The most relatable experience around binary G-code begins with a simple moment: slicing a model, saving the file, and noticing the extension is no longer the familiar .gcode. That tiny change can feel suspicious. Makers are naturally cautious people. They will happily install a custom hot end at midnight, but a new file extension? Absolutely alarming.

In a typical 3D printing workflow, the benefits show up quietly. A large model that used to take longer to transfer now uploads faster. A folder that once looked like it was preparing to consume the entire storage card becomes more manageable. Print previews still work in supported environments, and the printer starts normally. When everything is compatible, binary G-code is almost boring, which is exactly what a file format should be. The best infrastructure does not demand applause; it just stops getting in the way.

The friction appears when a workflow includes tools that do not yet understand .bgcode. For example, a user who slices in PrusaSlicer but sends jobs through OctoPrint may discover that the file needs conversion or that binary export should be disabled. This is where binary G-code feels less like a universal upgrade and more like an ecosystem feature. It works beautifully when all the pieces are speaking the same dialect. When one tool is still expecting plain text, the conversation gets awkward.

There is also a psychological adjustment. Many users like knowing they can open G-code and inspect it. Even if they rarely do, the option is comforting. Binary files remove that instant readability. Yes, conversion tools restore access, but the workflow changes from “open and edit” to “convert, edit, convert back.” For casual users, that is fine. For tinkerers who frequently add custom pauses, purge lines, temperature tweaks, or experimental commands, plain text still feels friendlier.

In print farm scenarios, binary G-code becomes more compelling. When dozens of files move between slicer, storage, printer, and management software, reduced file size can save time and reduce clutter. Metadata blocks may also become valuable because operators care about material, nozzle size, printer compatibility, estimated duration, and job identity. A more structured format fits that environment better than a giant text file with scattered comments.

The best practical lesson is not that binary G-code should replace ASCII G-code everywhere. It is that machine files are evolving. 3D printers are no longer just stepper motors reading simple movement instructions from an SD card. They are networked manufacturing devices with previews, sensors, remote dashboards, firmware updates, job queues, and increasingly complex slicer output. Binary G-code is one attempt to modernize the humble file at the center of that workflow.

For now, the smart move is to treat .bgcode as a useful option rather than a moral crusade. Use it where it is supported. Disable it where it causes trouble. Keep conversion tools handy. And remember: whether the file is text or binary, the printer still has one jobturn plastic spaghetti into something that looks intentional.

Conclusion

Binary G-code is not a flashy invention in the way a faster printer or exotic filament might be. It is infrastructure. But infrastructure matters. By shrinking files, organizing metadata, supporting checksums, and staying convertible back to traditional G-code, the proposed .bgcode format addresses real weaknesses in the old text-based approach without throwing away decades of G-code logic.

The format’s success will depend on adoption. In supported Prusa workflows, it already makes sense. In mixed environments, traditional ASCII G-code remains the safer and more compatible choice. The future may not be entirely binary, but it is almost certainly more structured, more efficient, and less tolerant of giant text files waddling across networks like overfed penguins.