JSON6 Numbers Reference

JSON allows one number form: an optional minus sign, integer digits with no leading zero, an optional fraction and an optional exponent. JSON5 relaxes that by allowing hexadecimal, a leading plus, a leading or trailing decimal point, Infinity and NaN. JSON6 keeps all of JSON5 and adds binary, octal, underscore separators, leading zeros, repeated signs and signs separated by spaces. The README states the organizing idea: "a numeric token means what Number() says it means," with deliberate departures only for underscores and a leading or trailing dot.

The rest of this page gives the exact rules and the edge cases found by running each form through json-6 1.1.7.

Three prefixes switch the base. Each prefix may be written in upper or lower case, and hexadecimal digits may be in either case. A prefix with no digits after it is an error, and a digit outside the base is an error. None of the three accepts a fraction or an exponent.

Binary and octal literals are useful in hardware, protocol and permission tables, where a hex or bit pattern is the natural way to say a value. A register map such as { ctrl: 0b1000_0001, mask: 0xFF00, mode: 0o644 } reads cleanly and parses without a build step.

This is the most surprising rule if you come from C, Java, Go or sloppy-mode JavaScript, and the README devotes a whole section to defending it. A number written with a leading zero followed by more digits is decimal. It is not octal and it is not an error.

The README's reasoning is that the leading-zero-is-octal convention belongs to source code lexers, while every text-to-number routine in every language (Number("0123"), parseInt("0123", 10), Python's int("0123"), C's strtol) reads it as 123. It also notes the practical benefit: tables such as [ 001, 002, 010, 100 ] line up in columns. Anyone who wants octal has 0o.

Infinity and NaN are JSON5 inheritances. They are written exactly with that capitalization; infinity, INFINITY and nan throw, and Inf throws "Incomplete keyword". Signs work: -Infinity, +Infinity, -NaN (which is NaN) and +NaN all parse. The README notes explicitly that "-NaN results as NaN."

These values cannot be represented in JSON. JSON.stringify(NaN) gives null, which silently changes the data. JSON6.stringify writes NaN, Infinity and -Infinity as themselves so a JSON6 round trip preserves them, but a JSON consumer cannot read the output.

As an unquoted object key, Infinity and NaN are strings like any other bare word, so {Infinity: 1, NaN: 2} has the keys "Infinity" and "NaN".

An unquoted object key that looks like a number is still a string key, and by default it keeps its source text. {1e3: true} gives the key "1e3", {0x10: 1} gives "0x10" and {1_000: 1} gives "1_000". JavaScript would convert a numeric literal key through its numeric value, giving "1000" for the first. The normalizeNumericKeys option closes that gap by replacing the key with String(Number(key)).

The README warns that Number("0123") is 123 while a JavaScript literal 0123 in sloppy mode is 83, so combine the option with esStrictCompatible if the file also needs to be valid JavaScript. More about key rules is on the objects and arrays page.

See Also