Data Architecture

Naming Convention Checker

Paste names, pick a case convention, and get the ones that break it with the rename already written.

Loading the tool…

Processing happens locally in your browser. What you paste or load is processed by this page and is not uploaded to a server. Nothing is stored unless you use a control that says it stores something, and you can clear anything this site has kept from the privacy page.

How to use this tool

  1. Paste your names, one per line. A CSV header row pasted on a single line is split for you.
  2. Leave the convention on Detect from the list to check the names against each other, or pick one to check them against a rule.
  3. Select Check names.
  4. Work down the suggested rename column. Download the table as CSV if the rename list is going into a ticket.

What naming convention checker does

A naming convention is arbitrary and that is the point. There is no argument that snake_case is better than camelCase; there is a very strong argument that having half a schema in each is worse than either, because every query then carries a small tax of remembering which table you are in, and every generated artefact downstream inherits the inconsistency.

Paste one name per line, or paste a CSV header row and it will be split for you. Each name is reported with the style it is currently written in, whether it matches the convention you chose, and the rename if it does not. Left on automatic, the convention is taken from the majority style in the list itself, which is usually the question you actually have: not whether the names match a rule, but whether they match each other.

Frequently asked questions

This page checks one thing: whether your names are written in a consistent case. That is a convention — arbitrary, and valuable only because it is consistent. The naming standards validator checks the rules that have a reason behind them, such as reserved words, illegal characters, length limits and type names smuggled into column names. Most schemas need both, and they are separate pages because they are separate arguments.

It counts how many names are already in each style and checks everything against the majority. In a schema that already exists, that is usually the real question — not whether the names match snake_case, but whether they match each other. Single lower-case words such as email are valid in several styles at once, so they are reported as ambiguous and do not decide the vote on their own.

Whichever your platform and your team already lean towards. snake_case is the default across PostgreSQL, most SQL dialects and the analytics tooling that sits on top of them, because unquoted identifiers are case-folded and camelCase silently stops surviving the round trip. camelCase and PascalCase are common in application-owned schemas where the ORM maps directly to class and property names. The wrong answer is two conventions in one schema.

Yes, and that is the point of getting the list first. Every view, query, report, dashboard, pipeline and downstream contract that names the column has to change with it. This tool produces the rename list; deciding whether the consistency is worth the migration is a judgement about how much of your platform is still ahead of you.