BRev snake_case converter
snake_case lowercases everything and joins words with underscores: parse_xml_file, user_id, created_at. It is the most readable of the joined styles because the separator is explicit — no reliance on capital letters to find word boundaries — which is why it dominates in languages that value that, and in places where case is unreliable.
SQL is the strongest example of “unreliable”. Unquoted identifiers are case-folded — PostgreSQL folds to lowercase, Oracle and DB2 to uppercase — so a column created as userId comes back as userid unless it was quoted, and then it must be quoted forever afterwards. snake_case sidesteps the entire problem: the name survives every fold unchanged, which is why database schemas converge on it regardless of the application language.
The result is a boundary that most systems have to cross: a Python or Rails backend with snake_case columns, serving a JSON API whose keys are camelCase, consumed by a JavaScript front end. Somebody has to translate, and the choice is where — a serialiser layer, an ORM alias, or bulk conversion of a set of names, which is what the bulk mode below is for.
snake_case — worked through
Every line below is produced by the same converter that runs on this page, so the example and the tool cannot disagree.
| Input | snake_case | Note |
|---|---|---|
| parse xml file | parse_xml_file | The canonical shape of this style. |
| parse the XML file from the ERP API | parse_the_xml_file_from_the_erp_api | Acronym preservation on — the converter’s default. |
| parse the XML file from the ERP API | parseTheXMLFileFromTheErpAPI | Converted back to camelCase. Listed acronyms are restored; anything not on the list returns as an ordinary word. |
Where snake_case is the convention
| Ecosystem | What it applies to |
|---|---|
Python | PEP 8 specifies snake_case for functions, variables, methods and modules. It is enforced by every common linter and formatter, so it is effectively the language’s grammar. |
Rust | Functions, variables, modules and crate names. rustc emits a non_snake_case warning otherwise — the compiler itself pushes you into it. |
SQL / databases | Tables and columns, because unquoted identifiers are case-folded (down in PostgreSQL, up in Oracle). snake_case is the only style that survives that unchanged. |
Ruby / PHP / C | Ruby uses it for methods and variables (with PascalCase classes); modern PHP follows PSR-12 with camelCase methods but snake_case is still common in older code and in C standard-library style. |
The acronym trap
Acronyms collapse cleanly here because everything is lowercased: XML becomes xml, ERP becomes erp, so parse_xml_file has one obvious form. The information loss shows up on the way BACK, and it is selective: converting parse_xml_file to camelCase recovers parseXMLFile only because XML is in the acronym list, while app_erp_code returns as appErpCode whatever you do — nothing in the lowercase form records that ERP was an initialism. So a round trip through snake_case is lossy for exactly the terms your own project invented, which is the argument for adding your product acronyms to the list before converting a batch of names a downstream system will match by exact string.
مرحبا بالعالم. The Unicode slug keeps the original script.FAQ
Why does Python use snake_case?
PEP 8, the language’s style guide, specifies it for functions, variables and modules, and the ecosystem’s linters and formatters enforce it. Class names are the exception — those are PascalCase.
Should database columns be snake_case?
In general yes. Unquoted SQL identifiers are case-folded, so a camelCase column silently becomes lowercase in PostgreSQL and uppercase in Oracle unless quoted — and quoting it once means quoting it everywhere thereafter.
How do I convert snake_case to camelCase for an API?
Convert at the serialisation boundary rather than renaming your own code: an ORM alias, a serialiser configuration, or a bulk conversion of the field list. The converter below does bulk mode for exactly that job.