Protocol Buffer Formatter

Format and indent .proto (Protocol Buffer) files for readability.

Input .proto

Formatted output

syntax = "proto3";
package example;
import "google/protobuf/timestamp.proto";

message User {
  int32 id = 1;
  string name = 2;
  string email = 3;
  repeated string roles = 4;
  google.protobuf.Timestamp created_at = 5;
}

service UserService {
  rpc GetUser(GetUserRequest) returns (User);
  rpc ListUsers(ListUsersRequest) returns (ListUsersResponse);
}

message GetUserRequest {
  int32 id = 1;
}

enum Status {
  STATUS_UNKNOWN = 0;
  STATUS_ACTIVE = 1;
  STATUS_INACTIVE = 2;
}

Protocol Buffer Formatter — clean, indent, and beautify .proto files

Protocol Buffers (protobuf) is Google's language-neutral data serialization format. The .proto schema file defines messages, services, and enums that are compiled into language-specific code. This formatter normalizes indentation to 2 spaces, adds blank lines between top-level declarations, and ensures consistent brace placement — making large .proto files with dozens of messages far easier to read and maintain. It handles message, service, enum, and nested types correctly.

Built and maintained by Meet Shah · Last updated 25 July 2026

What this tool is used for

Making a hand-edited `.proto` file readable before review.
Normalising indentation across files from different contributors.
Reading a definition pasted without formatting.
Checking the nesting of a deeply structured message.
Preparing a definition for a documentation snippet.

Frequently Asked Questions

What is the standard .proto style?: Two-space indentation, `CamelCase` for message and enum names, `lower_snake_case` for fields, and `SCREAMING_SNAKE_CASE` for enum values — set out in Google's own protobuf style guide, which is the closest thing the format has to a formal convention.
Why are field numbers more important than names?: Because the wire format encodes the number, not the name. Renaming a field is a compatible change; renumbering one silently reinterprets old data as a different field. Numbers 1–15 use a single-byte tag, so they belong to the most frequent fields.
What does `reserved` do?: Blocks a field number or name from being reused after deletion. Without it, someone adding a field later can pick a retired number, and old serialised data will decode into the new field as a different type — a data corruption bug with no error message.
What changed between proto2 and proto3?: proto3 removed `required` — because a required field can never be safely removed — and made every field optional with a zero default. That means an unset scalar and a scalar set to zero are indistinguishable, which proto3 later softened with explicit `optional`.
Does formatting affect the generated code?: No. Whitespace and layout are irrelevant to the compiler, so formatting is purely for the humans reading and reviewing the schema — which is a real concern, because a `.proto` file is an API contract that outlives most of the code around it.

Common errors and gotchas

Expecting it to validate, since a syntactically odd file can format and still fail to compile.
Reformatting a file the project's own tooling formats differently, producing churn.
Assuming field numbering is checked, which formatting does not touch.
Losing a comment that documented a reserved field number.
Reformatting and committing alongside a real change, which hides it in the diff.