Need help with your JSON?

Try our JSON Formatter tool to automatically identify and fix syntax errors in your JSON. JSON Formatter tool

Ada Language JSON Libraries and Format Converters

If you searched for Ada JSON, the practical answer in 2026 is not just "yes, Ada can do JSON." The real question is which library fits your project, how much streaming support you need, and whether you are building a standalone tool or working inside a larger Ada framework.

For most new projects, GNATCOLL.JSON is the safest place to start. If you want a smaller dedicated package, json-ada remains a good lightweight option. If you are already using the VSS text stack, JSON support has moved into vss_extra.

Quick Answer

  • Use GNATCOLL.JSON when you want the most established general-purpose choice with both tree-style and incremental parsing APIs.
  • Use json-ada when you want a focused JSON package and you are comfortable with its parser/generic-package style.
  • Use vss_extra only when your codebase already depends on the newer VSS ecosystem and you want JSON support there.
  • For format conversion, expect to combine a source-format parser with a JSON writer. There is no dominant "universal converter" package in the Ada ecosystem.

Current Ada JSON Libraries

Checked against current primary sources on March 11, 2026, the Ada ecosystem has a few realistic JSON paths rather than a huge field of competing libraries. That is useful because the decision is usually clearer than in larger language ecosystems.

GNATCOLL.JSON

AdaCore's GNATCOLL.JSON documentation shows two important modes: a normal in-memory JSON tree and an incremental parser API for larger streams. The current Alire package listing exposes gnatcoll version 26.0.0.

  • Best default for service code, CLI utilities, and mixed-tooling projects that already use other AdaCore libraries.
  • Supports reading, writing, object and array manipulation, and lower-level parsing when you do not want to build the full tree first.
  • A good fit when payload sizes vary and you do not want to paint yourself into a DOM-only corner.

json-ada

The json-ada repository describes a standalone parser, DOM model, pretty printer, and optional duplicate-key checking. Alire currently lists it as the json crate at version 6.0.0.

  • Smaller and more focused than GNATCOLL when you only need JSON and do not want a broader utility collection.
  • Uses generic packages, so the setup feels a little more Ada-like and explicit than looser parser APIs in other languages.
  • The project documentation still notes that escaped Unicode sequences such as \uXXXX are not supported yet, so test this early if you process third-party API payloads.

VSS JSON via vss_extra

If your application already uses the Visual String Suite stack, JSON is now tied to the newer split repositories rather than the old monolith. The original AdaCore VSS repository was archived on October 6, 2025 and points developers to vss-text and vss-extra. Alire currently lists vss_extra 26.0.0 as a work in progress.

  • Relevant if you are already committed to VSS strings, text, and related infrastructure.
  • Not the clearest first pick for a new project whose only requirement is JSON parsing or pretty-printing.

AWA and Framework-Specific Layers

If you are already inside the Ada Web Application ecosystem, using its JSON support can reduce dependency churn. That said, search visitors looking for a general Ada JSON answer usually want a library they can add to any project, and in that narrower sense GNATCOLL.JSON and json-ada are the cleaner starting points.

Which Library Should You Choose?

  • Pick GNATCOLL.JSON if you want the most balanced default, especially for long-lived applications or mixed-size payloads.
  • Pick json-ada if you prefer a dedicated JSON package and do not need GNATCOLL for anything else.
  • Pick vss_extra if your team already standardized on the split VSS stack and wants to stay inside that ecosystem.
  • Pick a framework-specific layer only when the rest of your application is already built around that framework.

Real Ada Examples

The earlier generic pattern most articles use is not very helpful. These examples use actual package names so you can recognize the APIs you will see in documentation and code search.

Parse and pretty-print with GNATCOLL.JSON

with Ada.Text_IO;    use Ada.Text_IO;
with GNATCOLL.JSON; use GNATCOLL.JSON;

procedure Gnatcoll_Json_Demo is
   Root : JSON_Value := Read ("{""name"":""Ada"",""kind"":""language"",""year"":1983}");
begin
   if Has_Field (Root, "name") then
      Put_Line ("Name: " & Get (Root, "name"));
   end if;

   Set_Field (Root, "formatted_by", "Offline Tools");
   Put_Line (Write (Root, Compact => False));

exception
   when Invalid_JSON_Stream =>
      Put_Line ("Input was not valid JSON.");
end Gnatcoll_Json_Demo;

This style is a good fit when you want a normal JSON object model first and only move to incremental parsing when payload size demands it.

Parse a document with json-ada

with Ada.Text_IO;
with JSON.Parsers;
with JSON.Types;

procedure Json_Ada_Demo is
   package Types is new JSON.Types (Long_Integer, Long_Float);
   package Parsers is new JSON.Parsers (Types);

   Parser : Parsers.Parser := Parsers.Create ("{""tool"":""json formatter"",""valid"":true}");
   Value  : constant Types.JSON_Value := Parser.Parse;
begin
   if Value.Contains ("tool") then
      Ada.Text_IO.Put_Line (Value ("tool").Value);
   end if;
end Json_Ada_Demo;

Keep the parser object alive while you use the parsed value tree. The project README explicitly documents that lifetime requirement.

Format Conversion in Practice

Searchers also look for "Ada JSON converters," but in practice most Ada teams build conversions as small pipelines instead of pulling in one big conversion framework.

  • Parse the source format with the best library for that format, not with a JSON library.
  • Map the parsed data into Ada records or an intermediate object model you control.
  • Serialize the result with GNATCOLL.JSON, json-ada, or your framework's JSON layer.
  • Run the output through a formatter and validator so whitespace, escaping, and accidental trailing edits do not become deployment bugs.

That workflow is usually better than searching for a magic XML-to-JSON or CSV-to-JSON Ada package, because the mapping rules nearly always depend on your domain model anyway.

Common Pitfalls

  • Unicode edge cases: json-ada still documents missing support for escaped Unicode code points, so do not assume every web API payload will parse cleanly without tests.
  • Large documents: tree-style parsing is convenient, but GNATCOLL's incremental parser is a better fit when payload size or memory pressure matters.
  • Type mapping: JSON numbers, nulls, missing fields, and optional record components still need explicit Ada-side rules.
  • Schema validation: validation is usually a separate concern. Most Ada JSON libraries focus on parsing and writing, not full JSON Schema tooling.

Bottom Line

For most people searching for Ada JSON support today, the shortest useful answer is this: start with GNATCOLL.JSON, choose json-ada when you want a smaller dedicated package, and treat VSS JSON as an ecosystem-specific option rather than the default first recommendation.

Once you have working output, use a formatter to normalize it before shipping. That is the fastest way to catch broken escaping, malformed edits, and hand-written sample payloads that almost look valid but are not.

Source Notes

Library status in this article was checked against current primary sources on March 11, 2026: AdaCore's GNATCOLL.JSON docs, the Alire package index for gnatcoll, json, and vss_extra, the json-ada project README, the archived AdaCore VSS repository notice, and the Alire listing for AWA.

Need help with your JSON?

Try our JSON Formatter tool to automatically identify and fix syntax errors in your JSON. JSON Formatter tool