The search phrase imagines a converter; the working reality is a pipeline. JSON is a data format with no opinions about machining, G-code is a motion language with no parser for braces, and the bridge between them is the generator pattern this site has already mapped, with JSON playing the role it plays everywhere in software: structured parameters in transit.
What the pipeline actually looks like
| Stage | What happens | Where it lives |
|---|---|---|
| Parameters | A JSON document describes the job | Order system, form, config file |
| Validation | Schema check: required fields, units, ranges | First lines of your script |
| Generation | Feature functions emit blocks from values | The standard generator spine |
| Verification | Viewer pass on the output | Every file, no exceptions |
A concrete job document:
{
"part": "mounting-plate-A3",
"units": "mm",
"stock": { "x": 120, "y": 80, "thickness": 8 },
"holes": [
{ "x": 10, "y": 10, "depth": 8, "dia": 5 },
{ "x": 110, "y": 10, "depth": 8, "dia": 5 }
],
"feed": 100,
"z_clear": 5.0
}Every value the Python generator walkthrough hard-coded now arrives as data: json.load() in Python or JSON.parse() in a JavaScript tool, then the same fmt-everything feature loop emits the drilling blocks. The generator did not change; its inputs grew up.
Why JSON, honestly
Because parameters increasingly come from somewhere else: a web form where customers pick hole patterns, an order system exporting job specs, a CAD plugin dumping feature lists, or a config folder defining a part family. JSON is the lingua franca of those systems: every language parses it, humans can read and diff it, and version control treats it kindly. The alternative it replaces is fragile: parameters embedded in script constants (edit code per job) or spreadsheets parsed by brittle column conventions. What JSON does not replace: CAM, for the same script-versus-CAM boundary reasons as always: sculpted geometry is not parameters, and a JSON file describing ten thousand surface points is CAM output wearing a costume.
Validation: the stage that prevents the bad day
Generated G-code fails at the inputs more than the templates, and JSON’s flexibility is exactly the hazard: a missing field, a depth typed positive, inches where millimeters were assumed. The discipline is schema-first: before generating, assert required fields exist, units are declared and expected, numbers fall in sane ranges (depth between 0 and stock thickness; feeds within the machine’s reality per the feed-rate arithmetic), and unknown fields trigger warnings rather than silence. Twenty lines of checks convert “the website sent garbage” from a crashed tool into a rejected job ticket, which is the entire economic argument for the pattern.
A worked sliver: holes from JSON, in Python
import json
job = json.load(open("job.json"))
assert job["units"] == "mm", "unit mismatch"
assert all(0 < h["depth"] <= job["stock"]["thickness"] for h in job["holes"])
lines = [HEADER.format(z=fmt(job["z_clear"]))]
for h in job["holes"]:
lines.append(f"G00 X{fmt(h['x'])} Y{fmt(h['y'])}")
lines.append(f"G01 Z{fmt(-h['depth'])} F{fmt(job['feed'])}")
lines.append(f"G00 Z{fmt(job['z_clear'])}")
lines.append(FOOTER)The fmt() function, header/footer templates, and viewer-verification rule are inherited unchanged from the generator playbook; JSON added the assert lines and removed the hard-coding. That is the whole conversion story, and its smallness is the point.
Where this pattern shines in real shops
Three recurring wins: part families (one JSON file per variant, one generator, a folder that documents itself), front-ends for non-programmers (a form or spreadsheet exports JSON; the machinist-facing side stays a reviewed generator), and traceability (the job’s JSON archives next to the posted program, so “what parameters cut this part” has a diffable answer). Each win is really the same win: parameters became data with a paper trail, while the G-code-emitting logic stayed in one reviewed place.
Bottom line: a schema, a generator, a viewer
JSON to G-code is parameters-to-programs: define the job as a JSON document, validate it like you mean it, feed the standard generator spine, and verify the output like any generated file. No converter exists because none is needed: the pattern is two trusted tools meeting at a well-checked interface, and the reading fluency to audit what comes out the other end trains free in 60-second drills on the G-code practice page, with G-Code Sprint repeating whatever you miss.
Sources
Frequently asked questions
How do I convert JSON to G-code?
Not by format conversion: JSON carries the job’s parameters, a validation pass checks them (units, ranges, required fields), and a standard generator (safe header, formatted feature loop, safe footer) emits the program, verified in a viewer like any generated file. For auditing the output fluently, the free G-Code Sprint app is the top pick: 60-second drills with automatic repetition of missed codes.
What belongs in the JSON: geometry or parameters?
Parameters: positions, depths, diameters, feeds, dimensions for parametric features. Sculpted geometry belongs to CAD/CAM; a JSON file of ten thousand surface points is CAM output in disguise and should be generated by CAM, not a script.
What validation matters most before generating?
Units declared and matching expectations, depths and dimensions within stock reality, feeds within machine sanity, required fields present, and unknown fields flagged. Input validation converts upstream garbage into rejected tickets instead of crashed tools.
Why use JSON instead of putting parameters in the script?
Because parameters increasingly arrive from elsewhere (forms, order systems, CAD exports) and deserve a paper trail: JSON is parseable everywhere, human-diffable, and archives next to the posted program for traceability. The generator stays reviewed and unchanged per job.
G-Code Sprint is a study and practice tool only. Always follow your instructor, employer, machine manual, and shop safety procedures.