Compared with jc and jo

Two established tools cover most of what jz does. jc converts the output of commands, file formats and strings to JSON. jo builds JSON from shell arguments. jz does a part of each: COMMAND | jz overlaps with jc, and jz new overlaps with jo. This page lists the differences as they stand and does not rank the tools. Each one is the better choice for some jobs.

The versions compared are jc 1.25.7 (released 2026-06-18, MIT licence), jo 1.9 (released 2022-11-04, GPL-2.0-or-later) and jz v0.9.0 (released 2026-09-22, MIT licence). jc has been developed since 2019 and jo since 2016. jz’s first commit was in September 2026. jc and jo are packaged by the major Linux distributions and Homebrew. jz is installed with go install, a Homebrew tap, the AUR, or the packages on its release page. No code or fixture from either tool is copied into this repository.

In short #

• Use jc when you need a Python library, the Ansible filter, YAML output, line slicing, or input jz does not read: XML, TOML, plist and X.509 files; strings such as URLs, JWTs, timestamps and IP addresses; commands jz has no definition for, such as traceroute, iptables, dmidecode, wg, ufw, acpi, mdadm, ntpq, pacman, find, finger and zpool status; and more /proc files. When jz has to detect the format of a short output, jc was faster on one core and held less memory in the benchmarks below.
• Use jo when you need the smallest and fastest program for building JSON, type guessing (n=1 becomes a number and a=$(jo b=1) nests an object without extra syntax), base64 file contents, or adding keys to an existing JSON document.
• Use jz when you want the format detected from the text instead of named, input that does not fit refused rather than read partly, parsers defined in YAML without code, or command output, data files and argument-built JSON from one binary.

What jsonize does not do #

• It does not query, sort, aggregate, or reshape JSON. Use jq for that.
• It does not replace a command’s native JSON output. Prefer native output when available.
• It does not parse arbitrary free-form text. Input must match a known or explicitly defined format.
• It does not guess when input is ambiguous. Specify --parser, or conversion fails.
• It does not silently discard input that it cannot parse.
• It does not fetch parser definitions or access the network during conversion.
• It does not invoke a shell for jz run; shell syntax is interpreted only when you explicitly run a shell.

A definition can still name lines that are not data, such as headings, total lines, comments and the df: messages printed before a table. Those lines are left out of the JSON without a message. --explain counts them.

Command output: jc and jz #

The output of the two differs in key names, in which values are converted, and in which texts each accepts. Coverage has a fixture-by-fixture comparison. It uses jz’s own fixtures, which were chosen for jz’s definitions, so its counts favour jz and do not measure how often either tool is right on text in general.

JSON from arguments: jo and jz new #

The difference in value types is the one most likely to matter:

$ jo version=1.10 zip=007 enabled=true note=
{"version":1.1,"zip":7,"enabled":true,"note":null}

$ jz new version=1.10 zip=007 enabled:=true note=
{"version":"1.10","zip":"007","enabled":true,"note":""}

jo’s guess saves writing :=. A value that looks like a number loses its spelling unless its type is forced (jo -- -s zip=007).

Benchmarks #

These are the timings of one process per call, measured with himorime from bench/compare/himorime.yaml and written into this page by make bench-docs. They measure time, CPU time and peak memory only, not whether the JSON is correct.

jz is built as the release is built (CGO_ENABLED=0, -trimpath, -ldflags "-s -w") from the commit named under the tables. jc 1.25.7 is installed from PyPI; its prebuilt binaries were not measured. jo 1.9 is built with meson and stripped.

The df -h and ps aux input is captured on the machine that runs the suite, and ps aux is repeated to 100,000 rows. The CSV has 100,000 generated rows, a third of them with a quoted field that holds a comma. Before measuring, a setup step checks that both tools return the same number of records, and that jz new and jo build the same JSON.

jz has three ways to read command output, and they cost different amounts. Detecting the format (COMMAND | jz, jz-detected below) reads all built-in definitions, because any of them could fit the text. Naming the parser (--parser NAME, jz-parser) and running the command (jz run COMMAND) read only the definitions that answer to that name. jc always reads only the parser it is given.

jz loads its definitions and reads large input on several threads, and jc runs on one. Each case is measured twice: with every core available, and pinned to one core with taskset -c 0 (the rows ending in “one core”). The pinned figure is closer to what a machine or container limited to one core sees. Starting taskset is part of the pinned figures, which is most of the pinned time of jo and jz new.

In the tables, Relative is a command’s median time divided by that of the jz command its case compares against: jz-parser for command output, and the only jz command otherwise. CPU time is user plus system time. Peak RSS is the largest resident set size of the process.

jz, jc and jo #

One process per call on the same input.

Latency #

Relative is the median divided by the baseline command’s median, or by the fastest command’s.

Throughput #

Throughput is the declared work divided by the latency of each run.

CPU #

CPU values are medians over runs of the process tree. Utilization is CPU time divided by wall-clock time; above 100% means more than one CPU was busy. Process tree: the command plus every descendant its parent waited for (rusage); a descendant left running or reaped by init is not counted.

Memory #

Peak RSS is a resident set size, not the heap size of a language runtime. Peak RSS is the largest peak of any single process of the tree (rusage ru_maxrss), not the combined memory of processes running at the same time. ≤ marks a peak RSS at or below what the process starting the command already used; the command used at most that much.

Measured with himorime v0.1.2 on linux/amd64, AMD RYZEN AI MAX+ 395 w/ Radeon 8060S (32 logical CPUs), head 2a3a868d8e2e, seed 3688326356035415.

• go: go version go1.26.6 linux/amd64
• jc: jc version: 1.25.7
• jo: jo 1.9
• jq: jq-1.8.1
• taskset: taskset from util-linux 2.41.3

Reading the figures #

• Starting the process: jz printed its version in about 1.5 to 1.7 ms, jo in about 0.6 to 0.9 ms, and jc in 30 to 36 ms. Most of jc’s time on short input is starting Python and loading jc.
• With the parser named, or with jz running the command, jz read a short df -h report in about 6 to 8 ms and jc in 35 to 72 ms.
• When jz detects the format of a short output, jc was faster on one core (35 ms against 55 ms) and held less memory (21 MiB against 30 MiB). On all cores jz was slightly faster, using about five times the CPU time: detection reads every built-in definition and compiles the signatures it checks.
• On 100,000 rows of ps aux and on a whole CSV, jz was faster than jc on both core settings, detected or named: about 2.2 to 2.4 times for ps aux and 1.3 to 1.6 times for the CSV. It held about the same memory as jc for ps aux and less for the CSV.
• Streaming a CSV, jz was about 2.5 times as fast as jc on both core settings and held about half the memory.
• jo was about 3.5 times as fast as jz new on all cores and about 1.5 times pinned to one core. Both finish in about a millisecond, so the difference matters when a script starts the program thousands of times. Their peak memory is below what this measurement resolves (the rows marked ≤): both used less than the process that started them.
• These results come from one machine and one run of the suite, and jc’s figures depend on the Python version. Run make bench-docs to measure another machine.