EEEE84M3i·Sep 21, 2025
This is interesting, but how does this do on the conformance tests?
https://github.com/nst/JSONTestSuite
In Sj.h: A tiny little JSON parsing library in ~150 lines of C99nst
JSONTestSuite
C++2016–2025
nst / JSONTestSuite
JSONTestSuite
A comprehensive test suite for RFC 8259 compliant JSON parsers
8Distinct people
8Mentions
0Explicit recommenders
1.2KGitHub stars
What to know before exploring
What it is
A comprehensive test suite for RFC 8259 compliant JSON parsers
GitHub
Where it is used
No documented product use has been verified yet.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year8 dated mentions
Observed mentions: 2016-10-26 15:46:52 UTC to 2025-09-21 17:05:24 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 1 | 1 | 0 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 3 | 0 | 3 |
What Hacker News says
8 sourcesThat's right, KSON the language is any string that parses successfully as KSON. We have a formal grammar for the language [1], and once we validate/harden the design through our beta, we plan to express that in a spec, and we plan to provide a test suite for external implementations to validate themselves against (likely something similar to https://github.com/nst/JSONTestSuite).
I don't think warnings will be part of the spec, though classes of errors may be specified (TBD). This will allow, for instance, implementations that prioritize pure speed by leaving all the guardrails off and simply replying "NO." when they are unable to parse some KSON (and then possibly falling back to a parse with richer validations?).
But languages are more than syntax, they are also the ecosystem of tools around the language. And for a language to be useful
Read the rest
and reliable, that ecosystem of tools needs to be excellent, and it needs to be available on any platform you want to use that language. That's a really important motivator for KSON's multiplatform architecture, which allows us to reach all these platforms[2] and editors[3] (with even more to come!)
[1] https://github.com/kson-org/kson/blob/857d585ef26d9f73e080b5...
[2] https://kson.org/docs/install/#languages
[3] https://kson.org/docs/install/#editor-support
You need more than a standard; that standard has to be complete and unambiguous. What you're looking for is https://github.com/nst/JSONTestSuite
EDIT: The readme's results are from 2016, but there's more recent results (last updated 5 years ago). Of the 54 parsers /versions tested, 7 gave always the expected result per the spec (disregarding cases where the spec does not define a result).
In A love letter to the CSV formatA comprehensive test suite for RFC 8259 compliant JSON parsers
2 points · Open discussionBecause of this article (which I encountered a year ago) I would say Parsing JSON is no longer a minefield.
I had to write my own JSON parser/formatter a year ago (to support Java 1.2 - don't ask) and this article and its supporting github repo (https://github.com/nst/JSONTestSuite) was an unexpected gift from the heavens.
In Parsing JSON Is a Minefield (2018)> The bigger question is, what is there to be done?
Something like https://github.com/nst/JSONTestSuite? Could a parser test suite be an official component of an RFC like 8259?
In Parsing JSON Is a Minefield (2018)Number handling looks like it would be a problem. There are Test suites for json parsers and lots of parsers that fail a lot of these tests. Check e.g. https://github.com/nst/JSONTestSuite which checks compliance against RFC 8259.
Publishing results against this could be useful both for assessing how good this parser is and establishing and documenting any known issues. If correctness is not a goal, this can still be fine but finding out your parser of choice doesn't handle common json emitted by other systems can be annoying.
Regarding the numbers, I've run into a few cases where Jackson being able to parse BigIntegers and BigDecimals was very useful to me. Silently rounding to doubles or floats can be lossy and failing on some documents just because the value exceeds max long/in t can be an issue as well.
In Simdjson – Parsing Gigabytes of JSON per SecondWow! This was a great practical analysis of existing implementations, besides a great technical overview of the spec(s). Thanks for open sourcing the analysis code[1], and for the extended results[2]
[1] https://github.com/nst/JSONTestSuite
[2] http://seriot.ch/json/parsing.html
In Parsing JSON is a Minefield