Real protobuf needs a .proto schema. How does this work without one?

It doesn't use a schema at all, it assigns field numbers itself, in the order your JSON object's keys appear (the first key becomes field 1, the second field 2, and so on). This is legal wire-format protobuf, but it's only meaningful to you because you know what each field number means; a real protobuf consumer needs a .proto file to make sense of it.

What is the field map legend at the bottom of the output for?

It's a field N -> "key" line for every top-level key, telling you exactly which field number corresponds to which original JSON key, so you can hand-write a .proto message definition (e.g. string key = N;) that matches the bytes above it.

Why does the top-level JSON value have to be an object?

Protobuf messages are always a set of numbered fields, there's no concept of a bare top-level array or scalar the way JSON allows, so the converter requires a JSON object at the root, matching how every real .proto message is structured.

How are nested objects and arrays encoded?

A nested object is encoded as a length-delimited embedded message using the same sequential field-numbering scheme independently within that nested object. An array is encoded as an unpacked repeated field, each item gets its own tag and value under the same field number, which every protobuf decoder accepts regardless of whether the field was declared packed.

JSON to Protobuf Converter - Encode JSON Online (Schemaless)

Overview

Introduction

Protobuf is normally generated from a .proto schema by protoc, but sometimes you just want to see what a JSON object looks like on the wire, for debugging, learning the format, or building a quick test fixture, without setting up a full schema and codegen pipeline.

This tool encodes JSON directly into protobuf's binary wire format, assigning field numbers itself and printing a legend so the mapping back to your original keys isn't lost.

What Is JSON to Protobuf Converter?

A schemaless protobuf encoder: it walks a JSON object's keys in order, assigns each one a sequential field number starting at 1, and writes each value using protobuf's varint, 64-bit, length-delimited, or 32-bit wire types depending on the value's JSON type.

The output pairs a hex byte dump with a field N -> "key" legend, since the bytes alone carry field numbers but never field names, protobuf's wire format has no concept of a key string at all.

How JSON to Protobuf Converter Works

Each object key is assigned a field number equal to its position (first key is field 1, second is field 2, ...), and encoded with a tag byte combining that field number and a wire type: 0 for integers and booleans, 1 for 64-bit values, 2 for strings and nested messages, matching the real protobuf wire format.

Nested objects recurse through the same encoder independently, so a nested object's own keys are numbered 1, 2, 3, ... within that nested message, exactly as they would be if you'd written a separate message type for it in a .proto file. Arrays are encoded as an unpacked repeated field, one tag-and-value pair per item under the same field number.

When To Use JSON to Protobuf Converter

Use it when you want to see how a JSON payload would look as protobuf bytes without writing and compiling a .proto file first.

It's also useful for generating a quick protobuf test fixture, then hand-writing the matching .proto message definition using the printed field-number legend.

Often used alongside Protobuf to JSON Converter, JSON to MessagePack Converter and JSON to BSON Converter.

Features

Advantages

Requires no .proto file, protoc installation, or codegen step to produce real protobuf wire-format bytes.
Prints a field-number-to-key legend, so the mapping needed to write a matching .proto file is never lost.
Handles nested objects and arrays with the same field-numbering logic protobuf itself uses for embedded messages and repeated fields.

Limitations

Field numbers are assigned purely by JSON key order, they will not match an existing .proto schema's field numbers unless your JSON keys happen to be in that exact order.
Booleans and small integers are wire-compatible in protobuf (both use wire type 0), so this is not reversible into the original type without a schema, decoding recovers a plain number, not true/false.
There's no way to express a proto field name in the output itself; the legend is the only record of what each field number originally meant.

Examples

Encoding a flat object

Input

{"name":"Ada","age":30}

Output

0a 03 41 64 61 10 1e

// field map
field 1 -> "name"
field 2 -> "age"

name becomes field 1 (a length-delimited string), age becomes field 2 (a varint), and the legend records both mappings.

Best Practices & Notes

Best Practices

Keep JSON key order stable and intentional if you plan to hand-write a .proto file afterward, since field numbers derive directly from that order.
Save the printed field map alongside the hex bytes, without it the field numbers are meaningless once you've moved on to a different JSON document.
Use consistent key order across related documents if you want their field numbers to line up under a shared .proto message.

Developer Notes

encodeProtobuf() in protobuf-core.ts assigns field numbers by iterating Object.entries() in insertion order and incrementing a counter, then dispatches each value to a wire-type-specific writer (varint for booleans and integers, a little-endian 8-byte float for decimals, length-delimited for strings and nested objects, and an unpacked repeated tag sequence for arrays); nested objects call the same encodeMessage() function recursively so field numbering resets to 1 within each embedded message, mirroring how independent .proto message types number their own fields.

JSON to Protobuf Converter Use Cases

Producing a protobuf test fixture from a JSON document without setting up protoc or a .proto schema
Learning how a specific JSON shape maps onto protobuf's wire types by inspecting the byte-level output
Reverse-engineering a starting point for a .proto message definition from example JSON data

Common Mistakes

Assuming the encoded field numbers will match an existing, independently-authored .proto schema; they only reflect this tool's own key-ordering scheme.
Passing a top-level JSON array instead of an object; protobuf messages are always field-based, never bare arrays.
Losing the field map legend and later being unable to tell what a field number in the raw bytes was supposed to mean.

Tips

Copy the field map legend into a comment above your hand-written .proto message so the two never drift apart.
Pair with Protobuf to JSON to see exactly how much information (like original key names) doesn't survive a schemaless round trip.

JSON to Protobuf Converter