Skip to content
FindTool

    Text Case Converter

    Convert between camelCase, snake_case, kebab-case, Title Case and eight more styles.

    Text Case Converter tool

    Useful for a column of identifiers pasted out of a spreadsheet.
    camelCase
    JavaScript variables, JSON keys
    —
    PascalCase
    Classes, React components, types
    —
    snake_case
    Python, Ruby, SQL columns
    —
    SCREAMING_SNAKE_CASE
    Constants, environment variables
    —
    kebab-case
    URLs, CSS classes, CLI flags
    —
    Train-Case
    HTTP headers such as Content-Type
    —
    Title Case
    Headings and page titles
    —
    Sentence case
    Body copy, UI labels, commit messages
    —
    lowercase
    Normalising before comparison
    —
    UPPERCASE
    Emphasis, legacy systems
    —
    dot.case
    Config keys, feature flags, namespaces
    —
    path/case
    File paths and route segments
    —

    What this tool does

    Type once and every case style appears at the same time, each with its own copy button. There is no dropdown, because the usual problem is not converting to a case you have in mind — it is that you know the shape you want and not its name. Seeing screaming_snake beside Train-Case beside dot.case settles that in a glance.

    The interesting work happens before any conversion: deciding where the words are. That step is what separates a converter that turns XMLHttpRequest into xml_http_request from one that produces x_m_l_http_request.

    Common uses

    • Renaming an API field across a stack — userAccountId in TypeScript, user_account_id in Postgres, USER_ACCOUNT_ID in the environment file, user-account-id in the URL.
    • Turning a Jira ticket title into a branch name, or a heading into a CSS class.
    • Converting a column of spreadsheet headers into identifiers — switch on "convert each line separately" and paste the whole column.
    • Writing an HTTP header name correctly: Content-Type is Train-Case, not content-type or Content_Type.

    A short example

    Given getHTTPResponseCode, the splitter finds four words and produces:

    camelCase             getHttpResponseCode
    PascalCase            GetHttpResponseCode
    snake_case            get_http_response_code
    SCREAMING_SNAKE_CASE  GET_HTTP_RESPONSE_CODE
    kebab-case            get-http-response-code
    Train-Case            Get-Http-Response-Code
    dot.case              get.http.response.code
    path/case             get/http/response/code

    How the word splitter handles acronyms

    Splitting is done with an ordered set of rules, and the order is the whole trick. The first rule peels a capital run off the front of a following capitalised word, which is why XMLHttpRequest becomes XML + Http + Request rather than XMLHttp + Request. The same rule recovers HTTP from the middle of getHTTPResponseCode and URL from the end of parseURL.

    Digits attach to the word they follow, so utf8Encoder splits as utf8 + Encoder and useHTTP2Pool as use + HTTP2 + Pool — not as a stray number in the middle. Existing delimiters (space, _, -, ., / and any punctuation) are boundaries, so already-converted input round-trips cleanly. Apostrophes are removed rather than split on, so user's profile gives usersProfile instead of userSProfile.

    Worth knowing

    Title Case and Sentence case work differently from the rest. They operate on your original text rather than on the split words, because punctuation and spacing carry meaning in a sentence and would be destroyed by rejoining. Title Case applies the usual convention of leaving short function words — a, of, the, to — lowercase unless they start or end the title, and leaves any word with an interior capital alone, so iPhone and macOS survive.

    The delimiter conversions are lossy in one specific way: case boundaries are the only record of where words begin, so converting ID to camelCase and back yields id, not ID. Acronym capitalisation cannot be recovered once it has been flattened into snake_case.

    Frequently asked questions

    Are HTTP header names case-sensitive?

    No. RFC 9110 §5.1 defines field names as case-insensitive, so Content-Type and content-type address the same field. HTTP/2 goes further: RFC 9113 §8.2.1 requires field names on the wire to be lowercase and says a message containing an uppercase one must be treated as malformed. Train-Case is a readability convention for docs and HTTP/1.1 dumps, which is why a test asserting exact header casing breaks the moment the connection is upgraded.

    Why do my camelCase Postgres columns need quotes forever?

    PostgreSQL folds every unquoted identifier to lower case, so CREATE TABLE t (userId int) really creates userid. The SQL standard folds to upper case instead, which is what Oracle does — neither preserves what you typed. Once a column exists as a quoted "userId", every query touching it must quote it identically. The common escape is snake_case in the database, camelCase in application code, converted at the boundary.

    Which case should a JSON API use?

    camelCase is the safe default: Google’s JSON Style Guide specifies it, and protobuf’s canonical JSON mapping rewrites a user_account_id field to userAccountId automatically, so a gRPC service exposed over JSON emits camelCase whether that was the plan or not. Consistency matters more than the choice itself — a payload mixing created_at with updatedAt guarantees someone writes the wrong accessor.