Protobuf to TONL Converter

Example: Protobuf input and real TONL output

The output below was generated by the same conversion code the converter uses, run on this sample when the page was built.

user {
  id: 42
  email: "dev@example.com"
  active: true
  roles: "admin"
  roles: "billing"
  profile {
    display_name: "Dev Ops"
    locale: "en-SE"
  }
}

#version 1.0
root:
  user{active,email,id,profile,roles}:
    active: true
    email: dev@example.com
    id: 42
    profile{display_name,locale}:
      display_name: Dev Ops
      locale: en-SE
    roles[2]: admin,billing

TONL output is 40% larger than the Protobuf input. The same data is 140 characters as minified JSON and 218 as pretty-printed JSON. Sizes are character counts, not tokens: token counts depend on the model's tokenizer (see the tokenizer comparison).

Protobuf to TONL: what changes

• Reading Protobuf: Input is Protobuf text format (the readable form used in .textproto files and debug output), not the binary wire format. Repeated fields are collected into arrays; no .proto schema is read, so types are inferred from the values.
• Writing TONL: TONL output starts with #version 1.0 and a root key, lists field names in braces, and sorts keys alphabetically. On small payloads the header and per-object field lists make it larger than TOON; TONL earns its place through its query, schema, and streaming tooling.

Why Convert Protobuf to TONL?

Use TONL when you want a compact text format plus tooling around it: querying, schema validation, or streaming. For plain prompt compression, TOON is usually the simpler choice.