Anywhere a human is reading or editing YAML/JSON/TOML, KSON may be used as a more effective interface on that data. If you are such a human, we invite you to participate in this beta.
tl;dr Check out the website [1], play with the online playground [2], install the library for your programming language [3], edit in your favorite editor [4], discuss and give feedback [5], contribute to the project [6].
(A personal note about this project: I love software. Machines made of words! Such a wonder. KSON itself, as a collection of words that both make a machine and explain that machine, is an expression of a lot ideas I feel really passionately about around software and our relationship to it. I've put a lot of love into trying to make that expression eloquent and reliable. I hope some of that comes through clearly, and I look forward to discussing this more over time with anyone who's interested)
One of the key things KSON wants to say is: let's keep everything that's great about YAML and JSON as "Configuration User Interfaces", and let's make those interfaces more toolable, robust, and fun. Here's some of the ways we do that:
- KSON is a verified superset of JSON, has native JSON Schema support, transpiles cleanly to YAML (with comments preserved!), and is likely available wherever you want it—current supported platforms: JS/TS, Python, Rust, JVM, and Kotlin Multiplatform.
- KSON is also widely available in developer tools, with support for VS Code, Jetbrains IDEs, and anywhere you can plug in an LSP.
- KSON is fully open source, licensed under Apache-2.0, and you are invited to meet its words and tinker with how they make its machine. A lot of care, craft, attention and joy went into making the KSON project understandable and approachable for developers. We hope to see you around.
PS. This is an HN-friendly version of the official announcement at <https://kson.org/docs/blog/2025/09/17/introducing-kson/>.
[1]: https://kson.org/
[2]: https://kson.org/playground/
[3]: https://kson.org/docs/install/#languages
[4]: https://kson.org/docs/install/#editor-support
```
%kson: level 1
%kson: level 2
%kson: level 3
- "a list"
- "of values"
%\\%
%\%
```
Note that for each level of nesting, the delimiters inside the block have to increase, instead of the ones outside. In a long embedded block you probably copied from elsewhere, you have to check every escaped delimiter to make sure it has the correct number of back slashes and update it. It would have made more sense to have a varying number of % correspond to a matching set to close it. e.g. %%%kson: foo matches %%% and closes it.
2. It's impossible to represent strings where every line has at least some leading indent, because they "always strip their minimum indent".
I think both these issues are solved by using zig's style of raw string literals. An embed block could start with %tag and each following line with % continues the block. No closing delimiter or delimiter escapes needed.
```
%kson: level 1
%%kson: level 2
% %%kson: level 3
% % % - "a list"
% % % - "of values"
% % % - "indented"
Granted, this also kind of looks ugly with percent signs. But the upside is you could paste in each sub level, and a text editor could insert the symbols for you before each line, just like they already do when highlighting text and commenting it out.
Like I understand I'll get syntax highlighting, multi-line formatting; seems great for devex, but why's stopping me from putting code in a single string and parsing it?
Does it offer some benefits while parsing it? Thanks!
By making the content type of the embed a first-class citizen of the syntax, together with clear boundaries for the embedded content, editors and IDEs can hook in all their great tooling to the embed blocks. So, you nailed it: being great for devex is exactly the idea.
What about manipulating the data?
Does it support embedded comments, like TOML does? What happens if you round-trip that through JSON? What about the other superset features?
What does KSON stand for?
There's a lot said about JSON and YAML on the main page, but why is this better than TOML?
KSON (stands for: KSON Structured Object Notation) is designed not as an nth standard, but rather as an idea of how to play nice with all n-1 existing standards. Since our comments (we do support comments!) are preserved in formatting and transpilation (provided the underlying language supports comments), you may use KSON as how you edit whatever underlying config file your system wants (currently YAML and JSON are supported, with a clear path to adding other targets like TOML <https://github.com/kson-org/kson/issues/202>)
Why is it better than TOML? We don't insist that everyone agree it is! But here's two ways to contrast them: - We prefer that KSON's recursive structure makes nesting consistent. You can see for instance in the grammar that a Kson list value is a list of Kson values: https://github.com/kson-org/kson/blob/857d585ef26d9f73e080b5... - For use cases where folks are hand-editing non-trivial config, especially if they are using embedded code blocks of any kind: if they long for more help from their tooling, KSON makes that tooling possible.
From there it could be compiled to targets declarative or procedural (eg to generate VegaLite specs, echart specs or Observable Plot configs in JS).
How have you been thinking about this problem space?
[0]: https://medium.com/@simardeep.oberoi/kyaml-kubernetes-answer...