All tools

Protobuf .proto Field Number Gap/Reservation Checker

Code

Parse a .proto file's message definitions and flag reused field numbers, gaps in the field-number sequence that aren't covered by a reserved or extensions statement, and field numbers outside the valid range, protobuf's own recommended practice for safe wire-format evolution.

Paste a .proto file and it checks each message's field numbers for three common mistakes: a number reused by two fields, a skipped number that isn't covered by a reserved or extensions statement (the thing that silently breaks wire compatibility when a field gets deleted and its number later gets reassigned), and a number outside protobuf's valid range of 1 to 536,870,911 or inside the 19000-19999 block reserved for the implementation. Nested messages get their own independent field-number space, and oneof fields count toward their enclosing message, matching how protobuf itself scopes numbers. It's a brace-depth parser rather than a full protobuf grammar, so it doesn't validate enum values or extend blocks.

protobufprotogrpcschemalint

How to use Protobuf .proto Field Number Gap/Reservation Checker

  • 1.Paste a .proto file's contents into the editor.
  • 2.Review each message's field list and any flagged findings, each with a rule name, the message it applies to, and a line number.
  • 3.Add a reserved or extensions statement for any flagged gap before deleting or renumbering fields in a message that's already shipped.

Frequently asked questions

Why does a skipped field number matter if nothing uses it?
If a field was deleted and its number isn't marked reserved, a future change could reuse that number for a completely different field, and any client still holding old serialized data would misinterpret the bytes. Protobuf's own style guide recommends reserving removed numbers for exactly this reason.
Does it check enum values or extend blocks?
No, both are out of scope: enum value numbers follow different rules than message field numbers, and extend blocks add fields to a different message's number space, not the extending block's own. Only message (and oneof) field numbers are checked.
How are nested messages handled?
Each message, including ones nested inside another message, gets its own independent field-number space, so two unrelated messages reusing the number 1 is never flagged as a conflict.
Is this a full protobuf parser?
No, it's a brace-depth parser tuned to find message/oneof blocks and field/reserved/extensions statements correctly. It doesn't validate full proto syntax, imports, or options beyond what's needed to scope field numbers.

Use via API, SDK, or MCP

cURL# Free: 1,000 req/day · Pro: 10,000 req/day
curl -X POST https://api.utilix.tech/v1/tools/proto-field-number-checker \
  -H "Authorization: Bearer utx_live_..." \
  -H "Content-Type: application/json" \
  -d '{"content":"message Person {\n  string name = 1;\n  int32 age = 5;\n}"}'

Get an API key from your dashboard · Full API docs →

Related tools

Conventional Commit Message LinterLint a git commit message against the Conventional Commits v1.0.0 spec: header format, blank-line separation, footer tokens, and BREAKING CHANGE casingCodeCSV Column Type InferencerParse CSV or TSV data and infer each column's data type (integer, float, boolean, ISO 8601 date, or string), flagging which columns are nullable and how many empty cells each one has.CodeDockerfile LinterLint a Dockerfile for unpinned base images, missing WORKDIR/USER, and misused ADDCode