json-accelerator trades runtime validation for a serializer built from your schema

The idea: serialise into bytes the Response can send as is

json-accelerator accelerates JSON stringification by providing an OpenAPI or TypeBox model. The mechanism is described in one sentence in the README, and that sentence is the whole design.

By providing the model ahead of time, the library generates a function that serialises the object into a Uint8Array which does not need to be re-encoded by Response.

That last clause is the point. The usual path in a web framework is to build a JavaScript string with JSON.stringify and then hand that string to a Response, which encodes it to bytes on the way out. Doing the encoding ahead of the fact, into a typed array, removes a step and lets the framework send bytes directly. The result is a function whose shape is known, so the serialiser can be specialised to that shape rather than inspecting every value at runtime.

The benchmark quoted in the README is the project's own claim, from a run of the medium manual benchmark:

$ npx tsx benchmarks/medium-manual.ts

clk: ~3.02 GHz
cpu: Apple M1 Max
runtime: node 22.6.0 (arm64-darwin)

summary
  JSON Accelerator
   2.12x faster than JSON Stingify
   2.66x faster than Fast Json Stringify

The reference to fast-json-stringify, which is the closest thing to a competitor in this space, is telling. That library also generates a serialiser from a schema, and it is the comparison the project chose to make.

Using it with TypeBox, and the shape of the API

The library is designed to be used with TypeBox 1 or later, though an OpenAPI schema should also work. The usage is short enough to read in one pass, and the type import comes from TypeBox while the accelerator factory comes from the library itself:

import { createAccelerator } from 'json-accelerator'

const shape = t.Object({
	name: t.String(),
	id: t.Number()
})

const value = {
	id: 0,
	name: 'saltyaom'
} satisfies typeof shape.static

const encode = createAccelerator(shape)

console.log(encode(value)) // {"id":0,"name":"saltyaom"}

The API is a single factory, createAccelerator, which takes the shape and returns the encode function. The value is typed with satisfies against the shape's static type, so the compiler checks that the object matches the schema, and the encoder is then called with it.

The package manifest also shows a second export path, a ./text entry point alongside the main one, and a peer dependency on typebox at version 1.0.0 or later that is marked optional, which is what allows an OpenAPI schema to be used instead of a TypeBox one. The main entry points are a CommonJS build at dist/cjs/index.js, an ES module build at dist/index.mjs, and type declarations.

The caveat: no type checking, and what happens when the shape is wrong

The caveat section of the README is blunt about the library's main limitation. This library will not check for the type validity of the schema, and it is expected that the schema is always correct. The suggested way to achieve that is to check the input validity with TypeBox before passing it to the accelerator.

const guard = Compile(shape)
const encode = createAccelerator(shape)

if (guard.Check(value)) encode(value)

The guard comes from the TypeBox compile module, and the pattern is the sensible one for a library that trades runtime checks for speed. You compile a validator once, and you run it before the fast path.

The failure mode is described next, and it is worth knowing exactly. If the shape is incorrect, the output will try to coerce the value into an expected model, and if it fails, an error is thrown. So the guarantee is not that bad input is rejected cleanly. The guarantee is that the encoder tries to make the value fit the schema it was given, and only fails loudly when it cannot.

There is an escape-check.ts file at the root of the repository, and the fact that it exists says this is a real concern the project is tracking. For a library whose whole premise is skipping validation, that file is the safety net that belongs in the same repository.

Installation, and who it is published for

The install is a single package with the four usual package managers:

# Using either one of the package manager
npm install json-accelerator
yarn add json-accelerator
pnpm add json-accelerator
bun add json-accelerator

The keywords in the package manifest list elysia, json, stringify and accelerator, and the repository is under the elysiajs organisation with the homepage and issue tracker on GitHub and the package published on npm. So this is a component of the Elysia ecosystem, and the reason it exists is that a framework that returns the same object shapes for every route has exactly the case this library optimises.

The author is SaltyAom, and the maintainer of the package in the manifest is that same person. The homepage given for the project is the npm package page.

For anyone evaluating it, the context matters more than the code. A general purpose JSON library competes with the built-in stringify on a case where the built-in is fast enough. A framework-specific accelerator competes on the case where the shape is fixed and the serialisation happens on every request, and the answer to whether that case exists in your service is the first question to answer.

The repository, the tooling and the test matrix

The repository layout is small and shows a project that is careful about the environments it runs in. There is a src directory, a test directory, an example directory with index.ts and server.ts, a benchmarks directory, a plans directory, and a build.ts that drives the build with bun.

The test script is the interesting part. It runs bun test, and then a separate test:node script that installs the package into two separate directories, one for CommonJS and one for ESM, and runs an index.js in each. That is a deliberate double check, because a library that ships both a require and an import build has to work in both, and the test verifies the built artefact rather than the source.

The dependencies in the manifest explain the rest. bun is the runtime for the build and the tests, mitata is the benchmarking harness, fast-json-stringify is the comparison baseline, tsx runs the benchmark scripts, and there is both tsdown and tsup in the development dependencies. The eslint and prettier configuration files, along with a .npmignore and a CHANGELOG.md, make it a conventional published package.

The release script runs the build, then the tests, then publishes with public access, which is the right order. The package version in the manifest is 0.2.0, while the published versions on npm are the 0.1.x series, so the manifest is ahead of what the registry shows.

Where json-accelerator is the wrong choice

The first limit is that the shape must be known ahead of time. That is the premise of the whole library, and it means it does not help the case where every request carries a different payload shape, such as an endpoint that echoes arbitrary JSON, or a schema built at runtime from a user-provided definition. There is no runtime-schema variant here.

The second is the validation gap, and it is the one to think hardest about. The library does not check type validity, and it coerces rather than rejects. If your service takes untrusted input and encodes it into a response, a schema mismatch becomes a data integrity problem rather than a caught error, unless you have added a guard. The README tells you to add one, and it is not optional in my view for anything that touches a request body.

The third is the platform assumptions. The output is a Uint8Array, and the premise is that a Response can send it without re-encoding. That is true in the runtimes and frameworks the project targets, and it may not be true in a runtime where the response body is expected to be a string, or in a framework that copies and re-encodes whatever it is given.

The fourth is the size of the win. The quoted speedups are from the project's own benchmark on an Apple M1 Max, and they are against a baseline that is already fast. If your service serialises a few hundred responses per second, the difference is invisible next to the network and the database. This is a library for a hot path, and for a cold path it adds a schema dependency and a validation step for nothing.

Licence, releases and the state of the project

The package is MIT licensed, with the LICENSE file at the root of the repository, and the description in the manifest is the same one-liner as the README, speed up JSON stringification by providing an OpenAPI or TypeBox model.

The release history is small. The published versions on npm are 0.1.7 from 2025-04-24, 0.1.6 from the same day and 0.1.4 from 2025-03-27, and the last push to the repository was on 2026-08-07 with the repository not archived. The manifest version of 0.2.0 is ahead of the published tags, which tells you the 0.2 line is in preparation rather than released.

That is a young project, and the version numbers are honest about it. A 0.1.x library with a single author, a single ecosystem and a narrow purpose is fine to evaluate on the benchmark, but it is not fine to depend on without pinning.

The topics in the repository metadata are accelerator, json and typescript, which is the honest description of a small focused package. There is no separate site, and the documentation is the README plus the source, which for a library with one exported function is proportionate.

Editorial conclusion

json-accelerator fits a service that serialises the same shape over and over, such as a hot API returning the same object type on every request, where the shape is already known at build time and can be handed to a code generator. It is the wrong tool for payloads whose shape varies per request, and it is the wrong tool for code that needs the encoder to validate input, since the library explicitly does not check type validity and expects the schema to be always correct. Before you adopt it, check three things: that the shape is fixed and known ahead of time, that you validate the input somewhere, either with a TypeBox guard or at the type level, and that the surrounding runtime supports a Uint8Array response body, which is what the whole design is built around. The code is MIT licensed, the package version is 0.2.0, the last push was on 2026-08-07, and the published versions on npm are 0.1.x.

Frequently asked questions

Official sources

1. elysiajs/json-accelerator on GitHub
2. License: MIT
3. Project website
4. README
5. Releases