Format and validate .proto files with proper indentation, field ordering, and syntax checking.
This tool takes a .proto file and re-emits it in canonical protobuf style: two spaces of indentation, single spaces around every equals sign, and message fields sorted by ascending tag number, following Google's protobuf style guide. It also checks the file against the proto3 grammar and reports syntax errors. The surprise is that the reordering is real, not decorative: the binary format addresses fields by number, so declaration order is pure presentation and the tool moves fields freely - but it never changes the numbers themselves.
A concrete input and expected output from the current implementation.
Input
syntax="proto3";
package demo;
message Person {
repeated string emails=5;
int32 age=2;
string name=1;
enum Status {
UNKNOWN = 0;
ACTIVE = 1;
INACTIVE = 2;
}
}
Expected output
syntax = "proto3";
package demo;
message Person {
string name = 1;
int32 age = 2;
repeated string emails = 5;
enum Status {
UNKNOWN = 0;
ACTIVE = 1;
INACTIVE = 2;
}
}
The fields were declared in tag order 5, 2, 1 with ragged indentation and cramped equals signs; the output normalizes indentation to two spaces per level, adds the single spaces, and sorts the fields by ascending tag number, leaving names, types, and numbers untouched. The nested enum gets the same treatment one level deeper.
The tool re-emits the file with canonical protobuf formatting: two spaces of indentation per level, a single space on either side of every equals sign in the syntax line, field declarations, and options, and message fields written in ascending tag order. Names, types, numbers, and default values pass through unchanged, so files that began as different authors' hand-edits end up looking alike and matching the style guide's conventions.
Before anything is reformatted, the file must parse as valid protobuf source. The check operates at the syntax level: braces and brackets balanced, semicolons where the grammar requires them, quoted strings closed, keywords spelled correctly, and a tag number present on every field. A problem is reported at the construct that caused it, so a missing semicolon is flagged directly rather than turning into garbled output.
No. Indentation, spacing, and declaration order are presentation; the binary wire format identifies fields by tag number, so a formatted file serializes exactly what the original did. The tool never changes numbers - renumbering would break schemas already in use, and fixing a duplicated tag number is left to you.
If the file trips an error about the first enum value, this is the rule behind it: in proto3 the first value of every enum must be 0, a language rule rather than a style preference, and a common leftover from proto2 files. The zero value is what an unset enum field defaults to. Add an explicit zero first, often named with an UNSPECIFIED suffix such as STATUS_UNSPECIFIED, and keep the remaining numbers.
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.