Convert Protocol Buffer definitions to JSON representation and vice versa with field mapping.
This tool converts Protocol Buffer definitions into the JSON representation that protobuf-JSON APIs and gRPC gateways expect, and it converts JSON back into proto3 message definitions. It parses the .proto text, then applies the protobuf JSON mapping to each field: snake_case names become lowerCamelCase, 64-bit integers become strings, bytes become base64, enums become their value names. The surprise for most users is that this renaming is not the tool's choice; the specification mandates it, so order_id legitimately appears as orderId in the output.
A concrete input and expected output from the current implementation.
Input
syntax = "proto3";
message Book {
string title = 1;
string author_name = 2;
int64 isbn = 3;
repeated string tags = 4;
} Expected output
{
"title": "",
"authorName": "",
"isbn": "0",
"tags": []
} author_name becomes authorName because the JSON mapping names fields in lowerCamelCase, and isbn is an int64, which the mapping requires to be a string. The values shown are defaults; a real serialized message would omit empty string, empty array, and zero-valued fields entirely.
Every field gets a JSON name: the lowerCamelCase form of the proto field name by default, or the explicit json_name option when the .proto declares one. In the JSON-to-proto direction the tool accepts both the camelCase name and the original proto name, matching how protoc-generated code parses JSON.
int32, uint32, and other 32-bit integers stay JSON numbers; int64, uint64, sint64, fixed64, and sfixed64 become strings; float and double become numbers, with NaN, Infinity, and -Infinity encoded as strings; bytes become base64; enums become their value names; repeated fields become arrays; map fields become objects; nested messages become nested objects. Going from JSON back to proto, the tool infers types from values, which forces guesses such as int32 versus double for a plain number.
Because JSON numbers are IEEE-754 doubles and cannot represent every 64-bit integer exactly, the protobuf JSON mapping specification requires 64-bit integer types to be encoded as strings while 32-bit types stay numbers. Any conforming serializer does the same; there is no option to turn it off.
Only by declaring an explicit name in the proto: the spec sets the JSON name to the lowerCamelCase form unless the field carries a json_name option, which overrides it. Add json_name = "order_id" to the field and the JSON key becomes order_id. Without that option, no conforming tool keeps the underscore form.
The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.
Format, validate, and beautify JSON with syntax highlighting and error detection.
Encode text or files to Base64 and decode Base64 strings back to their original form.
Format and indent SQL queries for better readability across all major dialects.
Convert HTML markup into clean Markdown syntax with support for tables and lists.
Write Markdown and see the rendered HTML output in real time with live preview.
Visualize unified diffs and patch files with color-coded additions and deletions.