Text Case Format Converter

Why convert offline?

Most case conversion tools are server-backed. When you paste text into them, the full string, which might contain variable names, internal code snippets, or identifiers you would rather keep private, is transmitted to a third-party server. For developers working with proprietary code or writers handling confidential drafts, that round trip is a meaningful privacy risk.

This tool uses vanilla JavaScript running entirely in your browser, so the text you paste never leaves your machine. All 14 case transformations happen locally using pure string manipulation applied character by character and word by word.¹ You can verify this yourself by opening DevTools, switching to the Network tab, and watching for outbound requests as you type: there are none, no matter how much text you process.

How local execution protects your text

Nothing you paste is read by any other machine, because the conversion code runs as plain JavaScript inside your page and never opens a network socket or writes anything to disk. That means variable names, configuration keys, and confidential identifiers stay on your device from the moment you type them to the moment you copy the converted result into your clipboard. There is no backend, no analytics call, and no hidden telemetry that could leak what you are working on.

Character case formats

The first table shows 5 character-level transformations. Each one works on every character in the string regardless of word boundaries, so the output depends only on the case of each individual letter and not on any detection of where one word ends and the next begins. There is no splitting step, which makes these formats fast and predictable even when the input is a single long token with no separators.

When to pick a character-level format

Choose a character-level format when you want a uniform transformation applied across the entire input, rather than a format that depends on splitting the text into words first. That makes them the natural fit for case-insensitive normalisation, for emphasis and stylised text in headings or messages, and for any situation where the structure of the input should not change.

• lower case. Converts every letter to lowercase. Use: normalizing user input, preparing strings for case-insensitive comparison, standardizing display text.
• UPPER CASE. Converts every letter to uppercase. Use: constants in programming, environment variables, SQL keywords, emphasis in headings.
• Capitalized Case. Makes the first character of each word uppercase and the rest lowercase. Use: proper nouns in prose, formatting names or titles in user-facing text.
• aLtErNaTiNg cAsE. Flips each character in sequence, so even positions become lowercase and odd positions become uppercase. Use: stylistic text effects, meme formatting, visual emphasis in informal contexts.
• InVeRsE CaSe. Swaps the case of every character, turning uppercase into lowercase and lowercase into uppercase. Use: stylistic text effects and obfuscating text while keeping it readable.

Word case formats

The second table shows 9 word-level transformations, each of which alters how words are recognised and rebuilt rather than how individual letters are cased. Understanding how the tool splits a string into words is the key to predicting what each output will look like, especially when the input mixes several separator styles or contains compound identifiers.

How word splitting works

Splitting recognises explicit separators (spaces, underscores, hyphens, dots, and slashes) and implicit compound identifier boundaries at the same time. It flags lowercase-to-uppercase transitions inside a run of letters, letter-to-digit transitions, and acronym edges where a sequence of capitals meets a following capitalised word. Because of that detection, getHTTPCode produces get / http / code and userID produces user / id without any manual cleanup, and mixed inputs such as hello_world-test still resolve into a clean word list before the joining step runs.

• camelCase. Lowercases the first word and capitalizes every subsequent word. Use: JavaScript identifiers and object keys, where project style often normalizes names before data moves between systems.²³
• PascalCase. Capitalizes every word in the identifier. Use: C# and .NET types and members, where Microsoft's guidelines use PascalCasing for public member, type, and namespace names.⁴
• snake_case. Joins every word with an underscore. Use: Python variables, functions, and module names, where PEP 8 recommends lowercase with underscores.⁵
• SCREAMING_SNAKE. The same as snake_case, but rendered in all capital letters. Use: constants and portable POSIX utility environment variables, where names use uppercase letters, digits, and underscores.⁶
• kebab-case. Joins every word with a hyphen. Use: CSS custom properties, where the CSS variables spec uses dashed names such as --main-color.⁷
• dot.case. Joins every word with a dot. Use: Java package names (com.example.app), configuration keys, semantic versioning references.
• path/case. Joins every word with a forward slash. Use: file system paths, URL path segments, directory structures, routing patterns.
• sentence case. Capitalizes only the first word and lowercases the rest. Use: prose sentences, user-facing messages, email body text, captions.
• Title Case. Capitalizes every word in the string. Use: headings, book titles, navigation labels, button text, card titles in UI design.

The same identifier in the five head conventions

One worked example shows the whole family at once. Take preferredShippingMethod, a three-word compound any API might carry: pasted into the input, it appears as preferredShippingMethod in the camelCase row, PreferredShippingMethod in PascalCase, preferred_shipping_method in snake_case, PREFERRED_SHIPPING_METHOD in SCREAMING_SNAKE, and preferred-shipping-method in kebab-case, all updated together. The differences between those rows are three small decisions: which words receive a capital letter, which character joins the words, and whether the first word starts with a capital. Every convention in the table is one answer to those three questions, and the rows show the answers side by side.

Reading that row set is the point of the exercise. One word list rebuilds every format, which is why a single paste answers every conversion direction at once: the row you arrived for sits on screen next to rows you did not know you needed. Note the SCREAMING_SNAKE row in particular, because many codebases call that format constant case and treat it as the spelling of a module-level constant. If you land here for one pair of conventions, you leave holding all five, with the boundary decisions visible instead of implied by a single convention's name.

What one paste converts

All 14 rows update from a single paste, but what the paste means differs by group. The character-level rows transform the entire block in place, so a multi-line list of names comes back fully converted in lower case, UPPER CASE, aLtErNaTiNg cAsE, and InVeRsE CaSe, with every line still where you left it. In the word-level rows, the paste itself is the identifier, and their split step treats a newline like any other separator, so a multi-line list merges into a single joined output. Those nine rows are built for one identifier per paste.

The workflow consequence follows from that split. For a list of 30 field names, the character-level rows handle the whole block in one pass, while the word-level workflow is paste-per-name: drop in each identifier, copy the row you need, and move to the next. There is no per-line batch mode for the word-level rows, because the split step joins everything it is given, and Use-as-input chaining covers the indirect transitions the direct rows miss. The honest summary is that block conversion and identifier conversion are two different jobs sharing one page.

Accented and non-Latin text hits the two groups differently, and the difference is worth knowing before you paste. The character-level rows use the browser's Unicode-aware casing, so accented letters and other scripts survive a lower case or UPPER CASE pass exactly as typed. Because the word-level rows keep only ASCII letters and digits, treating every other character as a separator, an accented letter drops out of the word list entirely and never reaches the rebuilt identifier. The practical boundary is simple: word-level output is always ASCII, and text carrying accents should use the character-level rows or be transliterated before any word-level conversion.

Chaining conversions

The "Use as input" button next to each row lets you chain transformations. Click it and the converted text becomes the new input, so the tool immediately recalculates all 14 formats based on the updated text. This is useful when you need to go from one format to another that the tool doesn't support directly. For example, you can start with a snake_case variable, convert it to camelCase, and then use that result as the input to produce kebab-case in a second step.

CapyToolkit offers this chaining workflow because real-world text transformations rarely fit inside a single conversion. Variable names move between languages when Python snake_case needs to become JavaScript camelCase. URL slugs evolve when a Title Case heading should become a kebab-case path for SEO. Configuration keys get normalized across systems when a dot.case property needs to turn into a SCREAMING_SNAKE constant. Chaining lets each of those shifts happen in place without losing the intermediate result.

Variable naming conventions across languages

Different ecosystems make casing part of their conventions. Python's PEP 8 recommends lowercase function and variable names with underscores, while JavaScript guidance uses camelCase for function names and PascalCase for class names.²⁵ Microsoft's .NET guidance uses PascalCasing for public member, type, and namespace names and camelCasing for parameter names.⁴ CSS custom property names start with two dashes, and the CSS variables spec shows dashed names such as --main-color.⁷

Moving code between these worlds is where conversion earns its place in a workflow. Copying a Python REST API response into a TypeScript interface means every snake_case field needs camelCase treatment before the types compile. Generating CSS variable names from a Figma token list means converting Title Case labels to kebab-case before they work as custom properties. Exporting database column names to an ORM model means snake_case columns become camelCase or PascalCase properties depending on the ORM's convention. Each step is mechanical, but doing it manually across dozens of identifiers invites slip errors that take real time to trace through compiled output and failing tests.

Configuration files and data formats add another layer. JSON object names are strings rather than a mandated casing scheme, while portable POSIX utility environment variables use uppercase letters, digits, and underscores.³⁶ A single project can pull data from multiple formats and require consistent naming before any of the data can be joined or compared. That work splits along the same line the converter does: a block of field names converts wholesale through the character-level rows, while word-level targets take one identifier per paste, so a 30-field list means 30 quick pastes rather than one bulk drop. Between the two jobs, the mechanical effort is still seconds against the hand-typing alternative, though the paste cadence is per identifier for the word formats. CapyToolkit's Text Case Format Converter handles all 14 formats in a single pass, so you pick the target format and every output updates simultaneously.

The same conversion also runs in code when a refactor is too large to paste. In any mainstream language, the standard library can perform it, and the routine is always the same three steps this tool runs: split the identifier into words using boundary rules, normalize each word's case, and join with the separator the target convention calls for. A regex or a handful of string methods covers the split for most inputs, while acronym edges and digit boundaries are the cases that reward a tested helper over a hand-rolled one-liner. Written once and reviewed, that helper then serves every future migration.