RE:Dox parses to a 64-bit token DOM, and the benchmarks are on its own hardware

One token representation under every format

RE:Dox is described as a high-performance, token-based structured data engine for .NET, developed as a core component of REX Technology for Capcom's next generation game engine.

The architecture is stated as a pipeline: a set of input formats, a compact token DOM or IR, and a set of readers, writers, serializers and deserialisers, ending in .NET objects and the various wire formats.

JSON / JSON5 / CBOR / MessagePack / TOML / XML / HTML / CSV / INI / DOX
        ↓
Compact token DOM / IR
        ↓
Reader / Writer / Serializer / Deserializer
        ↓
.NET objects, JSON, CBOR, MessagePack, TOML, XML, HTML, DOX, ...

The same token representation serves as both the parsed document model and the common structural layer shared by every serializer and converter. That is the part that matters: formats do not each get their own object model, they get one, and a converter written against the abstraction works across all of them.

The format split is not uniform, though. JSON, JSON5, CBOR, MessagePack, INI and DOX are integrated with the core model, while TOML, XML, HTML and CSV are described as currently preview components.

The design target is three properties that normally conflict

The README frames the project as combining three goals that usually conflict: the parse speed of a tape DOM as in System.Text.Json.JsonDocument, the editability of a node DOM as in System.Text.Json.Nodes.JsonNode, and the flexibility of Newtonsoft.Json, named specifically as position-independent $type, $id and $ref, and out-of-order constructor binding.

The consequences listed from that design are a mutable token DOM where you edit objects and arrays in place without replacing the document with a heavyweight managed object tree, trivia-preserving JSON5 editing where comments survive document edits and re-encoding, compatibility layers for System.Text.Json, Newtonsoft.Json and DataContractJsonSerializer, and one converter model across formats through DataConverter<T> targeting the format-agnostic DataReader and DataWriter abstractions instead of a specific wire format.

The core is a fixed-size 64-bit token with an extension bit

The architecture section describes the central data structure, and it is the clearest statement of what makes this engine different from a serializer with a fast path.

Every value is described by a fixed-size 64-bit token, and an extension bit selects how the payload is interpreted. With the extension bit at zero, payload interpretation is delegated to the document or format layer, which the text describes as source-backed and format-specific, with many formats sharing one token shape. With the extension bit at one, payload interpretation is fixed by RE:Dox itself, and control tokens enable format-agnostic behaviour.

That design has a direct consequence: the DOM is fixed-size per value, so an in-place edit does not require reallocating a new object tree. It is also why the same structure can carry formats as different as MessagePack and XML without the token layout changing.

The README section on that architecture is cut off partway through its description of the control token set, so the format-agnostic operations those tokens enable are not documented there. The docs/ directory in the repository is where that belongs.

Installing and using it: one package, one API surface

The core package installs through the dotnet CLI:

dotnet add package CAPCOM.REDox

The example that follows does serialization, deserialization, parsing and editing through the same API, which is the practical demonstration of the shared model claim:

using REDox.Json;

var player = new Player
{
    Name = "Leon",
    Level = 42,
    Items = ["Handgun", "Green Herb"]
};

var json = JsonSerializer.Serialize(player);
var restored = JsonSerializer.Deserialize<Player>(json);

using var doc = JsonDocument.Parse(json);
var root = doc.RootElement.AsObject();
root["Name"] = "Claire";
root.Add("Hp", 100);
root.Remove("Level");

Note the API shape. JsonSerializer and JsonDocument are both in REDox.Json, so the entry points mirror System.Text.Json's names while being RE:Dox's implementation. The editing surface is indexer assignment plus Add and Remove on the object, and AsArray() returning something with Add, Insert and RemoveAt.

The type being round-tripped is a plain sealed class with auto-properties, no attributes. That is the compatibility claim in concrete form: ordinary POCOs, no annotations.

Read the benchmark conditions before the speedup numbers

The performance section is unusually complete about its limits, and that is the most useful thing in it.

The environment is BenchmarkDotNet on .NET 10 with the x64 RyuJIT at x86-64-v3, on an AMD Ryzen Threadripper PRO 5975WX running Windows 11. The comparison baselines are System.Text.Json's JsonSerializer, System.Text.Json with JsonTypeInfo, and Utf8Json.

The headline speedups are up to about 1.8x for sequential deserialization, up to about 2.8x for automatic parallel deserialization and up to about 1.6x for serialization. Per dataset the numbers differ substantially: canada.json deserialises at 1.68x and parallel at 2.84x but serialises at only 1.06x, while citm_catalog.json manages 1.77x, 2.25x and 1.62x, and twitter.json 1.36x, 2.34x and 1.42x.

So the 1.8x and 2.8x figures are best case numbers drawn from canada.json, and the README says so: these ratios describe the benchmark datasets and are not universal performance guarantees. It also states that results depend on data shape, target type, runtime, CPU and serializer options, and instructs you to benchmark with your own workload.

Allocation is where the argument is strongest, not speed

The allocation figures are more consistent than the speed ratios, and for many workloads they are the number that matters.

On canada.json deserialisation, RE:Dox is listed at 9,113.0 us and 2,619.92 KB allocated, against System.Text.Json at 15,303.1 us and 8,734.66 KB, and Utf8Json at 15,864.0 us and 6,655.67 KB. The README summarises the same point in prose: canada.json deserializes with about 2.56 MB allocated by RE:Dox versus about 8.53 MB by System.Text.Json.

The pattern holds on the other two datasets with a smaller margin. citm_catalog.json is 553.55 KB against 1,175.38 KB, and twitter.json is 504.91 KB against 557.09 KB, where Utf8Json actually allocates less at 530.05 KB.

The parallel column is worth noticing for a different reason. RE:Dox parallel allocates slightly more than RE:Dox sequential on all three datasets, for example 2,685.11 KB against 2,619.92 KB on canada.json. The speed comes from using more than one core, and the extra allocation is the cost of that.

Benchmarks can be reproduced with:

dotnet run -c Release --project benchmarks/REDox.Json.Benchmarks

State of the project and where to look next

The releases are recent and the version numbering is fresh. v1.0.0 was published on 2026-10-01 and v1.0.1 on 2026-10-06, with the last push on 2026-10-14.

The repository layout shows the usual separation for a.NET solution. REDox.slnx is the solution file, alongside REDox.sln.DotSettings for the IDE. There is src/ for the libraries, benchmarks/ for the BenchmarkDotNet project, tests/, docs/, experimental/ and external/, plus scripts/ and image/. There are also.gitmodules, which suggests at least one dependency is vendored as a submodule.

Licensing is Apache-2.0, listed as one of the project features rather than buried at the end, and SECURITY.md and CODE_OF_CONDUCT.md are present with both English and Japanese contributing guides.

The description attributes the project to Capcom and calls it a core component of REX, which is the technology behind the next generation game engine. That origin is worth keeping in mind when reading the format list: it is an engine's data pipeline first, published as a general library second.

Editorial conclusion

Adopt RE:Dox if you have a .NET workload whose deserialization is genuinely hot and you can reproduce the benchmark on your own data, since the gains in the README are measured on three JSON datasets with a specific shape. Do not adopt it for a general purpose application without measuring, because the serialization gains are much smaller than the deserialization gains on one of the three datasets and the compatibility layers are there to make migration incremental rather than to guarantee parity. Verify first which formats you need, since JSON5, CBOR, MessagePack, INI and DOX are integrated with the core model while TOML, XML, HTML and CSV are preview components.

Frequently asked questions

Official sources

1. CAPCOM-TD-OSS/REDox on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases