DEV Community: Khaja Hussain

I Compared TOON vs Minified JSON Using OpenAI’s Tokenizer

Khaja Hussain — Tue, 12 May 2026 00:29:29 +0000

Recently I noticed a lot of developers talking about TOON:

The idea behind TOON is interesting. Instead of sending traditional JSON, TOON tries to reduce token usage and make data more compact for LLMs.

Since token costs are becoming a real concern for AI products, I wanted to test it myself.

Not theoretically.
Not with benchmarks from slides.
Just a simple real-world comparison.

I used OpenAI’s tokenizer tool and compared:

TOON format
Minified JSON

For the conversion process, I used:

JSON to TOON Converter
JSON Minifier

Minified JSON:

{"user":{"id":1001,"name":"Khaja","email":"khaja@example.com","roles":["admin","developer"],"settings":{"theme":"dark","notifications":true}}}

TOON version:

user:
id: 1001
name: Khaja
email: khaja@example.com
roles[2]: admin,developer
settings:
theme: dark
notifications: true
`

TOON Result: Tokens: 37
Minified JSON Result: Tokens: 38

That means TOON saved only 1 token in this example.

Honestly, that surprised me.

So… Is TOON Useful?

I think the answer is: yes, but with nuance.

TOON is not “bad.”
In fact, I actually like the direction.

It makes developers think seriously about:

token efficiency
AI-friendly data formats
prompt optimization
serialization overhead

Those are important conversations.

But after testing it, I’m not convinced that TOON alone will dramatically reduce costs for most companies.

In many cases:

removing whitespace already gives huge savings
gzip/brotli compression already works extremely well
AI models are already heavily trained on JSON structures

So the practical gains may be smaller than the hype suggests.

But Small Savings Can Still Matter at Scale

Here’s the interesting part.

Even tiny optimizations matter when companies process millions of requests.

Imagine:

10 million API calls
large AI prompts
multiple agents
long conversation histories

Saving even 1–2% tokens at scale could potentially save hundreds or thousands of dollars over time.

So I do understand why people are excited about TOON.

The Bigger Challenge: Ecosystem

Personally, I think TOON’s biggest challenge is not token count.

It’s ecosystem adoption.

JSON already has:

mature tooling
validators
parsers
database support
IDE integrations
API ecosystem dominance

Replacing that is extremely difficult.

In real production systems, compatibility usually matters more than tiny syntax improvements.

My Take

After testing both formats, my conclusion is:

TOON introduces interesting ideas
token savings appear modest in smaller examples
the ecosystem challenge is massive
but the conversation around AI-native serialization formats is valuable

I don’t think JSON is disappearing anytime soon.

But I do think experiments like TOON push the industry forward.

And honestly, that’s a good thing.

Would love to hear what other developers think or any suggestion what to compare next.

A free, high-performance backend for small projects — Cloudflare Workers in 10 minutes

Khaja Hussain — Sun, 03 May 2026 11:00:22 +0000

Every developer wants the same thing: a free way to run small backend tasks. A webhook for a side project. A contact form handler. An OG image generator. A small proxy to hide an API key. Things that handle a few hundred requests a week. They do not need a $20/month server, an Azure Function App you will forget about next month, or a new Lambda that takes an hour to set up.

I have had this problem for years. Most of my work is in .NET shops — AWS for production, Azure for clients on the Microsoft stack. Both are great for real workloads. Both feel like overkill when the actual task is "send me an email when a Stripe customer pays."

Last weekend I needed exactly that webhook. Spinning up a new Function App for one endpoint felt silly. Adding it to an existing production API would mix two unrelated things — the next person reading the code would wonder why a billing handler was sitting inside the customer-facing app. Every option I knew was way too much setup for one tiny task.

So I finally tried something I had been avoiding for three years: Cloudflare Workers. It solved the problem in ten minutes. Free, no credit card, deployed to 300+ data centres. Here is how it went, and why I should have tried it sooner.

Why I had been ignoring Cloudflare Workers

Three reasons:

No .NET story. I work in C#. Writing JavaScript at the edge felt like a whole new world just to deploy one small function.
The marketing made it look like big-company infra. Every Workers post I had read mentioned Durable Objects, R2, KV, Queues, AI bindings. It looked like a big platform you commit to, not a tool you grab for one task.
I thought the free tier was a trick. "100,000 requests per day" sounded like a number with hidden conditions and a credit-card requirement.

None of those were true.

The 10 minutes

Install Wrangler, the Cloudflare CLI:

npm install -g wrangler
wrangler login

The login opens a browser. Click approve and you are done. No credit card asked. I checked twice — I have been burned before.

Scaffold a project:

npm create cloudflare@latest stripe-webhook
cd stripe-webhook

Pick "Hello World" Worker, JavaScript, skip the deploy step. The generator puts everything in one folder. Open src/index.js and replace the default code with this:

export default {
  async fetch(request, env) {
    if (request.method !== 'POST') {
      return new Response('POST only', { status: 405 });
    }

    let event;
    try {
      event = await request.json();
    } catch {
      return new Response('Invalid JSON', { status: 400 });
    }

    if (event.type === 'checkout.session.completed') {
      const amount = event.data.object.amount_total / 100;
      const email = event.data.object.customer_email;

      await fetch('https://api.resend.com/emails', {
        method: 'POST',
        headers: {
          'Authorization': `Bearer ${env.RESEND_KEY}`,
          'Content-Type': 'application/json',
        },
        body: JSON.stringify({
          from: 'alerts@mydomain.com',
          to: 'me@mydomain.com',
          subject: `New payment: $${amount}`,
          text: `${email} just paid $${amount}.`,
        }),
      });
    }

    return new Response('ok', { status: 200 });
  },
};

Run it locally:

npm run dev
# Ready on http://localhost:8787

Send a fake Stripe payload with curl. Worked on the first try.

Deploy it:

npx wrangler deploy

Eight seconds later it printed a *.workers.dev URL. Total bundle size: 1.2 KB. I pointed Stripe's webhook config at that URL, sent a test event from the Stripe dashboard, and the email arrived in my inbox before the dashboard finished refreshing.

The part that surprised me

The free tier really is 100,000 requests a day. No credit card. The Worker runs in 300+ Cloudflare data centres at the same time. A Stripe webhook from San Francisco hits the San Jose data centre, my email goes out from Resend's nearest server, and the whole round trip takes under 200ms. No cold start. No Function App I have to remember to delete next month before it starts billing me.

If you store a webhook secret with wrangler secret put STRIPE_WEBHOOK_SECRET and verify the signature (you should — Stripe sends a Stripe-Signature header for this), the whole thing is still about 60 lines of code.

One gotcha worth knowing

If the request body is invalid JSON, request.json() throws a SyntaxError and Cloudflare returns a generic 500. That is bad for any user-facing endpoint, and it is worse for Stripe — Stripe retries on 5xx errors, so a broken parser quietly turns into duplicate retries while your dashboard looks fine. Wrap the parse in a try/catch and return a 400 with a clear message. Stripe webhook payloads are also big and hard to read; pretty-printing them with a JSON formatter makes debugging much faster. I learned the try/catch lesson the hard way — one panicked late-night Stripe dashboard refresh.

What I would do differently next time

Use Workers first for any small task that needs an HTTP endpoint. That is a much bigger category than just "webhook" — link shorteners, OG image generators, form handlers, edge auth, JSON proxies, internal Slack bots. Trying it is one npm create command away.

I feel a bit silly for waiting three years. The mental model is one sentence: a Worker is a function that takes a Request and returns a Response. That is the whole platform. Everything else (KV, Durable Objects, AI bindings) is optional. If you want the full step-by-step instead of the highlights here, this Cloudflare Workers deploy guide covers the whole setup with a real validating endpoint, the free-tier limits in detail, and a few more gotchas to know before you ship.

If you have been avoiding Workers like I was, try it on the next small task you hit. Fifteen minutes will tell you if it fits how you think. For me, it did.

Understanding Protocol Buffers: A Fast Alternative to JSON

Khaja Hussain — Sun, 15 Dec 2024 20:36:23 +0000

In the world of data interchange, JSON (JavaScript Object Notation) has been a long-standing favourite. It’s simple, human-readable, and works seamlessly across platforms. For many use cases, JSON is “good enough.” But as systems scale, and the need for speed and efficiency increases, JSON’s text-based format can become a bottleneck.

That’s where Protocol Buffers (Protobuf) come in. Developed by Google, Protobuf is a powerful, compact, and lightning-fast data serialization format that has become a popular choice for modern applications.

Why Consider Protocol Buffers Over JSON?
Compactness: JSON’s text-based format can result in larger payloads. Protobuf, on the other hand, uses a binary format, which dramatically reduces the size of the data.

Speed: Protobuf’s binary format is faster to serialize (convert data to a transferable format) and deserialize (convert back to usable data).

Schema Evolution: Protobuf includes a schema that defines the structure of your data, making it easier to evolve your APIs without breaking backward compatibility.

Efficiency at Scale: For applications with high traffic or limited bandwidth (e.g., mobile apps, IoT devices), Protobuf’s efficiency can result in lower latency and better performance.

Protocol Buffers: A Smarter Way to Handle Data
In the world of data interchange, JSON (JavaScript Object Notation) has been a long-standing favorite. It’s simple, human-readable, and works seamlessly across platforms. For many use cases, JSON is “good enough.” But as systems scale, and the need for speed and efficiency increases, JSON’s text-based format can become a bottleneck.

Why Consider Protocol Buffers Over JSON?
Compactness: JSON’s text-based format can result in larger payloads. Protobuf, on the other hand, uses a binary format, which dramatically reduces the size of the data.

Speed: Protobuf’s binary format is faster to serialize (convert data to a transferable format) and deserialize (convert back to usable data).

Schema Evolution: Protobuf includes a schema that defines the structure of your data, making it easier to evolve your APIs without breaking backward compatibility.

Efficiency at Scale: For applications with high traffic or limited bandwidth (e.g., mobile apps, IoT devices), Protobuf’s efficiency can result in lower latency and better performance.

A Quick Comparison: JSON vs. Protobuf
Let’s take a simple example. Imagine you’re sending information about a user:

Using JSON:

{
  "id": 123,
  "name": "John Doe",
  "email": "john.doe@example.com"
}

This is straightforward and human-readable. But it’s also relatively large because of all the extra characters like {}, :, and the field names.

Using Protobuf:
First, you define a schema (usually in a .proto file):

message User {
  int32 id = 1;
  string name = 2;
  string email = 3;
}

When serialized to binary format, this same data is compacted into a tiny, efficient payload—unreadable to humans but incredibly fast for computers to process.

When to Stick with JSON
JSON is still a fantastic choice for many use cases:

If human-readability is a priority (e.g., logging or configuration files).
For simple, low-traffic systems where performance isn’t critical.

When to Use Protobuf
If your application needs to:

Handle large-scale data exchange (e.g., microservices, real-time APIs).
Operate under bandwidth constraints (e.g., mobile or IoT devices).
Ensure compatibility while evolving the API schema.

JSON is like the comfortable, everyday car you drive around town—reliable and easy to use. Protobuf, on the other hand, is a sleek sports car—designed for speed, efficiency, and high performance. While JSON is great for most day-to-day tasks, Protobuf shines when you need to go the extra mile.

So, whether you stick with JSON or make the leap to Protobuf depends on your needs. But if you’re building for the future and performance is key, Protobuf is a solid choice to keep things running smoothly.

Some helpful links to understand Protobuf and Json:

Protocol Buffers Documentation
protobuf
Json
JSON in API Development