Text Case Format Converter

With UPPERCASE, every letter changes and no word boundary matters. It works on any text: code, prose, UI labels, or raw strings. SQL keywords are conventionally written in UPPERCASE for readability.¹ Constants, headings for certain design contexts, and abbreviations all call for all-caps output.

Converting prose or mixed-case text to UPPERCASE is a character-level operation, not a word-level one. The tool does not split on word boundaries or add separators: it simply maps every character to uppercase for review or export.

Where UPPERCASE text is used

SQL conventionally writes keywords in UPPERCASE: SELECT, FROM, WHERE, JOIN, GROUP BY.¹ Constants in many languages (C, Python, JavaScript) follow SCREAMING_SNAKE, which is uppercase with underscores, but when you need just the casing without underscores, this converter handles it. Building on this, design contexts like banner text, navigation section labels, and monospace UI headers often use all-caps for visual weight. Acronyms (API, URL, HTTP) are written in UPPERCASE in documentation. HTTP/2 and HTTP/3 protocol specifications render header field names in lowercase, but the older HTTP/1.1 convention of capitalized headers (Content-Type, Accept-Encoding) persists in many codebases and documentation examples.² Legal disclaimers, terms-of-service headers, and license agreement summaries frequently use UPPERCASE for emphasis, and some government forms require all-caps entries for machine readability.

Edge cases: non-letter characters and locale-sensitive casing

Numbers, punctuation, and special characters are not affected: they pass through unchanged. The converter uses JavaScript's built-in toUpperCase(), which is locale-aware but uses the browser's default locale.³ Consequently, locale-specific characters (like the German ß or Turkish i/I distinction) may produce unexpected results if the browser locale does not match the expected language. For ASCII text, this is never an issue. The German ß is a notable edge case: in most browser locales, toUpperCase() converts it to "SS", which changes the string length and may affect character-count-sensitive contexts like fixed-width displays. For Turkish text, whose case mappings do not follow Unicode's default mappings, the dotted/dotless I distinction means that "i" uppercases to "İ" (dotted I) in a Turkish locale but to "I" (standard I) in most other locales.⁴ If your application serves Turkish users, test uppercase conversion with Turkish-specific input to verify the output matches expectations.

Workflow: formatting SQL query keywords

Building on this, a practical use: when writing SQL queries in a text editor that does not auto-capitalize keywords, you can draft the query in mixed case and then use the UPPERCASE converter on just the keyword portions. CapyToolkit processes whatever you paste, so selecting specific lines and converting only those is the cleanest approach. For SCREAMING_SNAKE constants, use the CONSTANT_CASE converter instead: this converter does not add underscores. When formatting SQL for documentation or code review, paste the keyword list (SELECT, FROM, WHERE, etc.) to get the canonical uppercase form, then manually recombine them with your identifiers. SQL linters like sqlfluff enforce uppercase keywords by default,⁵ and running your query through this converter before pasting it into a migration file or stored procedure ensures it passes linting on the first attempt without manual keyword-by-keyword correction.

SQL keyword capitalization conventions across database systems

SQL keyword capitalization is not enforced by any database engine, but all major style guides recommend UPPERCASE for reserved words. Understanding why the convention exists helps you decide when to apply it and when to skip it. The convention persists across decades of database tooling because it makes SQL significantly more readable when scanning complex queries with multiple joins and nested conditions. When you uppercase a block of SQL keywords in one pass, the output gives you the canonical form that every major style guide expects, which means your query formatting matches what reviewers and automated linters look for before a migration reaches production.

PostgreSQL, MySQL, and SQLite treat SQL keywords as case-insensitive by the SQL standard.⁶ You can write select, Select, or SELECT and all three execute identically. The UPPERCASE convention survives because it creates a visual split between language keywords and your identifiers: SELECT user_id FROM users WHERE is_active = true scans faster than select user_id from users where is_active = true when reading unfamiliar queries. Linters like sqlfluff enforce uppercase keywords by default.⁵

When to skip UPPERCASE keywords

Query builders, ORMs, and code-generated SQL typically produce lowercase or mixed-case keywords because the output is not intended for human reading. If your SQL goes directly to an ORM method call or a query-builder chain, UPPERCASE keywords add no value. Apply UPPERCASE when the SQL is written or read by humans: in migration files, in database documentation, and in ad-hoc query tools like psql or TablePlus.

One more reason to skip automatic UPPERCASE is locale sensitivity. JavaScript's toUpperCase() depends on the browser's default locale, and for Turkish text the lowercase i maps to a dotted İ rather than a plain I. If you uppercase user-submitted names or labels that may contain Turkish characters, the result can look wrong to those users, so a targeted or language-aware transform is safer than a blanket conversion.

Comparing UPPERCASE output to CONSTANT_CASE for the right use

UPPERCASE and CONSTANT_CASE (SCREAMING_SNAKE) are easy to confuse because both produce all-capital letters. They serve different purposes and are not interchangeable. Choosing the wrong one produces output that either breaks identifier validation or fails to format SQL correctly. Knowing the distinction before you start saves the round-trip of converting the same text again. The key difference is whether you need separators between words: UPPERCASE keeps the original spacing while CONSTANT_CASE replaces spaces and word boundaries with underscores to produce a valid identifier. If you need a valid environment variable name or a Python constant, CONSTANT_CASE is the right choice because the underscores make it a legal identifier in every major programming language.

When UPPERCASE is the right tool

UPPERCASE converts a word or phrase without adding separators, which distinguishes it from CONSTANT_CASE formats. Acronyms (HTML, CSS, API), SQL keywords (SELECT, FROM, WHERE), and display-only all-caps text like banner headings all benefit from this simple transformation. The output has no underscores added: "background color" becomes "BACKGROUND COLOR", not "BACKGROUND_COLOR". Use this converter when you need visual emphasis or SQL formatting, not identifier naming.

When CONSTANT_CASE is the right tool

CONSTANT_CASE adds underscores between words while also converting every letter to uppercase: "background color" becomes "BACKGROUND_COLOR". This is the correct format for environment variable names, configuration constants in Python and JavaScript, and preprocessor macros in C and C++. If you need the output to be a valid identifier in a shell or programming language, use the CONSTANT_CASE converter instead of this one.

Use this when formatting SQL keywords, converting abbreviations to their standard uppercase form, or producing all-caps text for banner headings or constants that should not have underscores.

select id, name from users where active = true

SELECT ID, NAME FROM USERS WHERE ACTIVE = TRUE

html
css
api
url
http

HTML
CSS
API
URL
HTTP

Before comparing strings, generate slugs, or prepare search indexes, lowercase normalization removes avoidable ambiguity. When data arrives from user input or external APIs in mixed case, lowercasing it first makes the next processing step safer.

Yet lowercase is also a standalone output format for specific contexts: CSS property values, HTTP header names, and HTML attribute values are all lowercase by specification. Converting a list of mixed-case values in one pass avoids individual corrections.

Where lowercase normalization is required

Email addresses are case-insensitive by RFC 5321 specification,¹ but servers and databases compare them as strings. Storing emails in lowercase before indexing prevents duplicates like "[email protected]" and "[email protected]". URL paths in most web servers are case-sensitive on Linux but case-insensitive on macOS and Windows, causing cross-platform routing bugs.² Lowercasing all URL slugs before saving eliminates this ambiguity. Furthermore, HTML attribute values like type, rel, and method are specified as lowercase.³ HTTP header field names are case-insensitive by the HTTP specification,⁴ but many server implementations normalize them to lowercase internally. Search engines treat lowercase and uppercase URL variants as separate pages unless a canonical tag or redirect is in place, making lowercase normalization an SEO concern as well as a technical one.

Edge cases: locale differences and non-alphabetic characters

The converter uses JavaScript's toLowerCase(), which handles most Latin-script characters correctly. Locale-specific cases exist: the Turkish language distinguishes dotted I from dotless i, so lowercasing the dotted capital in "İSTANBUL" with the Turkish locale produces "istanbul" correctly, but JavaScript's default toLowerCase() does not apply the Turkish locale.⁵ For the vast majority of web application use cases (ASCII identifiers, email addresses, URL slugs), this is not a concern. Non-alphabetic characters (numbers, punctuation, emoji, CJK ideographs) pass through unchanged because they have no case distinction. The German ß lowercases to itself (it has no uppercase form in traditional German orthography, though the capital ẞ was added to Unicode in 2017). For applications that process multilingual content, testing with representative samples from each supported language catches locale-specific issues before they affect production data.

Workflow: normalizing user input before database storage

Building on this, a practical pattern: before inserting user-provided fields into a database (email addresses, usernames, and tags), run them through a lowercase normalizer. This tool lets you test the normalization with real data before writing the application code. Paste a list of raw user input samples, confirm the lowercased output looks correct, and use the same logic (str.toLowerCase() or str.lower()) in your application. CapyToolkit processes each line independently. For user-generated tags and categories, lowercase normalization at submission time prevents the common drift where "JavaScript", "javascript", and "Javascript" coexist as separate entries for the same concept. Running your existing tag list through this converter during a one-time migration identifies exactly which duplicates would merge, giving you a concrete count of the cleanup impact before you write the migration script.

Generating URL slugs with consistent lowercase output

URL paths on Linux servers are case-sensitive. "articles/my-Post" and "articles/my-post" resolve to different routes, and a capital letter in a slug causes 404 errors that are hard to trace in production logs. Lowercasing all URL slug components before saving prevents this class of error entirely. Building the lowercase normalization into your slug generation pipeline from the start is far cheaper than retrofitting redirects after search engines have already indexed inconsistent URLs. When you generate slugs from user-provided titles at request time rather than at publish time, a single lowercase call in your slug function ensures that every URL your application produces follows the same convention regardless of how the author capitalized the original title.

Slug generation from titles and headings

A typical slug pipeline takes a title ("My Blog Post"), lowercases everything, replaces spaces with hyphens, and strips non-alphanumeric characters. The lowercasing step is where inconsistency most often enters: a CMS field that accepts either case, a manually typed slug with an uppercase letter, or a title copied from a document in Title Case. Running the raw title through this converter before passing it to a slug function produces a consistent starting point. You then apply the hyphen and strip steps in your application code.

Canonical URLs and duplicate content prevention

Google treats https://example.com/Blog/Post and https://example.com/blog/post as separate URLs. If both exist, they split link equity and can trigger a duplicate content flag. Serving all URLs from lowercase paths and issuing 301 redirects for uppercase variants is the standard fix. Before generating URLs in bulk, run any user-provided path components through this tool to verify the lowercase form before writing the normalization into your application.

Testing normalization with real user input before writing application code

User input arrives in every capitalization shape. Before writing a normalization function, testing the logic against realistic data samples reveals edge cases that unit tests written in isolation may not cover. Building the lowercase normalization into your data pipeline from the start prevents the duplicate content and inconsistent lookups that arise when the same string arrives in different cases from different sources. Paste a sample of real user input from your application logs into this converter, verify the lowercase output handles every edge case you expect, and then implement the same logic in your production code with confidence that it covers the patterns your users actually submit.

Email address normalization across character sets

Most email servers treat the local part of an address as case-insensitive, but comparing stored emails requires a consistent format. Paste a sample of real email addresses from your signup form data into this converter and verify the lowercase output looks correct. Edge cases like addresses with multiple dots, plus signs, or domain parts with mixed case should all resolve to a predictable lowercase form. If any output surprises you, that reveals a gap in your normalization logic before you ship it.

Sub-addressing with the plus sign is preserved through lowercasing because the plus and everything after it sits in the case-insensitive local part. A user who registers [email protected] and later [email protected] keeps both aliases intact after normalization. The only characters that change are the letters, so tags and routing rules built on the plus sign survive the transform untouched.

Tag and category string normalization

Tags created by multiple authors in a shared CMS tend to drift: "javascript", "JavaScript", and "Javascript" exist as separate tags for the same concept. Lowercasing all tags at submission time (or during a one-time migration) collapses the duplicates. Paste your current tag list into this tool, copy the lowercase output, compare against your existing canonical tag list, and you can see exactly which duplicates would merge. CapyToolkit processes each line independently.

Use this when normalizing email addresses for storage, preparing strings for case-insensitive comparison, or formatting HTML attribute values, and to stop uppercase slugs from 404ing before user-supplied titles reach your routing layer on a case-sensitive server.

[email protected]
[email protected]
[email protected]

[email protected]
[email protected]
[email protected]

JavaScript
Web Development
Open Source
Machine Learning

javascript
web development
open source
machine learning

When every word needs equal visual weight, Capitalized Case gives you a simple rule. It makes every word start with an uppercase letter and lowercases the rest, which fits proper nouns in prose, product names in documentation, and formatted display text.

Capitalized Case differs from Title Case only in the treatment of the existing characters: Title Case on this tool produces the same result because both capitalize every word. The distinction matters in word processors that implement style-specific rules for articles and prepositions, but this tool applies simple word-boundary logic to all words for product labels and prose terms alike.

Where Capitalized Case is used

Product names in documentation and marketing copy use Capitalized Case: "User Authentication Service", "Payment Gateway Integration". Proper noun phrases in prose require it: "New York City", "North Atlantic Treaty Organization". Navigation labels in legacy software and some enterprise applications use Capitalized Case rather than the Sentence case preferred in modern design systems.¹ Building on this, database column display names, the text an admin UI shows for a column as opposed to its identifier, often use Capitalized Case.² Salesforce, HubSpot, and Airtable all use Capitalized Case for field labels throughout their interfaces,³ so when you build integrations that map database fields to these platforms, the display names should follow the same pattern. Academic reference lists in APA and Chicago styles use Capitalized Case for article and book titles,⁴ making this the expected format for bibliography entries in research software and citation management tools.

Edge cases: apostrophes, hyphens, and acronyms

Apostrophes in contractions and possessives do not start a new word: "it's" stays "It's" (not "It'S"). Hyphenated words count as one word, because only spaces separate words here: "well-known" becomes "Well-known". Acronyms already in UPPERCASE (like "API") get converted to "Api" because every letter after the first is lowercased. Consequently, for strings containing acronyms, review the output before use. Joined mixed-case inputs such as "UserProfile" count as one word and become "Userprofile", so separate the words with a space first if you want "User Profile". Single-character words like "a" and "i" capitalize to "A" and "I", which is correct for display text. Runs of spaces inside a line collapse to a single space, so accidental double spaces in pasted input do not survive into the result.

Workflow: formatting product name lists for documentation

Building on this, here is a common use: when writing feature lists or product category names in documentation, paste a list of raw lowercase or snake_case identifiers, convert to Capitalized Case, and copy the display names directly into your Markdown or HTML. CapyToolkit processes each line independently, so 30 product names convert in one pass. You get display-ready text without manually fixing each word's capitalization. For API documentation generated from OpenAPI specs, the summary and description fields often start as camelCase method names. Converting those to Capitalized Case before writing them into the spec produces human-readable endpoint descriptions in the generated docs without a separate formatting pass. When the API surface grows to hundreds of endpoints, this batch conversion saves hours of manual editing.

Formatting database column names as display labels in admin UIs

Admin dashboards and data tables need human-readable column headers. Database column names are snake_case by convention, but display labels in a grid or report need to be readable to non-technical users. Converting them in batch is faster than writing each label manually. Building a consistent display-label convention into your admin tooling from the start prevents the drift where every new column gets a hand-typed label that does not match the rest of the interface.

snake_case fields to display-ready strings

Paste a list of column names from your schema (first_name, created_at, is_email_verified) and copy the Capitalized Case output (First Name, Created At, Is Email Verified). Those are display-ready labels for a schema column, so use them as headers in your admin table, CSV export, or PDF report. CapyToolkit processes each line independently, so a 30-column schema converts in one pass. The result is display-ready copy without manual label writing.

A consistent display-label convention also helps downstream report generators and exporters. When the same column renders as "First Name" in a grid and as "first_name" in a CSV, analysts lose trust in the export. Running every schema column through this converter once, before the report template is built, guarantees that the grid header and the exported file use the same words. The Microsoft Power Apps guidance for column display names points in the same direction: readable labels beat raw identifiers wherever a non-technical user sees the data.

Matching display label conventions in enterprise software integrations

Enterprise tools like Salesforce, HubSpot, and Airtable use Capitalized Case for field labels throughout their interfaces. If you are building an integration or import tool that maps database fields to these platforms, using Capitalized Case for the mapped field display names creates visual consistency between your output and the target platform's existing UI. Users see labels that match the pattern they already recognize.

Capitalized Case versus Title Case in word processors and CMS tools

Capitalized Case and Title Case produce visually similar results, but they differ in one important way: Capitalized Case capitalizes every word without exception, while full Title Case implementations in style-guide-compliant tools lowercase articles and short prepositions. Knowing which rule applies to your context prevents output that looks correct on short phrases but breaks on longer ones.

Which to use when your CMS offers both options

If your CMS or word processor has a "Capitalize" option, it likely applies Capitalized Case (every word, no exceptions). An explicit "Title Case" option may apply Chicago or APA rules, lowercasing words like "of", "in", "the", and "a".⁵ For most display text in web UIs and data tables, Capitalized Case is what you actually want because the exceptions in APA and Chicago style only matter in formal publishing contexts. CapyToolkit's Capitalized Case converter applies the simpler, more predictable rule, making it the right choice for product copy and data labels.

Use this when formatting product names, proper noun phrases, database column display labels, or navigation items that should have every word capitalized.

first_name
last_name
created_at
phone_number

First Name
Last Name
Created At
Phone Number

user authentication
payment processing
order management

User Authentication
Payment Processing
Order Management

For text that needs a deliberately uneven rhythm, aLtErNaTiNg cAsE alternates uppercase and lowercase for every character in sequence. It carries a specific tone (ironic, mocking, or sarcastic) borrowed from internet meme culture.

Yet this is a character-level transformation with no word boundary awareness. Spaces, punctuation, and numbers are counted in the alternation sequence but do not change case themselves.

Where alternating case is used

Alternating case became widely recognized as the "mocking SpongeBob" meme format, where text imitates a sarcastic tone by alternating the case of each letter.¹ Social media platforms, Discord messages, and informal developer communication use it to signal disagreement or irony. Beyond meme contexts, some creative typographers use alternating case for stylistic effect in headings and banners. Programming humor contexts (documentation jokes, conference talk slides) sometimes include it as a deliberate contrast to formal code formatting. The format has also appeared in album titles, video game names, and street art, where the visual irregularity draws the eye and signals an intentional departure from conventional presentation. In user research and UX testing, alternating case is occasionally used in prototype text to signal "placeholder content" that participants should not read as final copy.

How the alternation works: character sequence, not word sequence

The converter assigns lowercase to even positions and uppercase to odd positions across the entire string.² Spaces and non-letter characters count toward the position index,³ which means the case of letters after a space depends on how many characters came before the space. Consequently, the same words produce different letter casing depending on where they appear in the string. This is by design: the irregular visual rhythm creates the characteristic staggered appearance. Punctuation marks like commas, periods, and exclamation points also count as positions, which means the casing pattern shifts after every piece of punctuation. For programmers, the indexing is zero-based: position 0 is lowercase, position 1 is uppercase, position 2 is lowercase, and so forth.⁴ The algorithm does not reset at word boundaries, which is why multi-word phrases produce a different visual pattern than converting each word in isolation.

Workflow: generating alternating case for meme captions

Building on this, the typical use is straightforward: type or paste your text, copy the alternating case output, and paste it into your message, caption, or document. The tool is intentionally lightweight, with no options for starting character or word-level vs. character-level alternation. It is especially useful when you need a caption to feel intentionally informal or playful across a social post. For more controlled visual patterns, use the aLtErNaTiNg output row directly on the main Text Case Format Converter tool. When generating test fixtures for a string-processing library, paste a known phrase into this converter, copy the exact output, and use it as the expected value in your test assertions. The deterministic alternation (same input always produces the same output) makes it a reliable source of expected test values without needing to compute the pattern by hand.

Alternating case as input for testing case-insensitive systems

Beyond meme formatting, alternating case has a practical application in testing: it produces input that exercises every case-handling branch of a case-insensitive function. No other single input string achieves this as efficiently. Security testing also benefits from alternating-case input: authentication systems that compare API keys, session tokens, or passwords should reject any case variation, and alternating-case test strings verify that the comparison is truly case-sensitive where it should be.³ Running a single alternating-case test through every comparison path in your application reveals case-handling bugs that would otherwise stay hidden until a real user submits mixed-case input in production.⁵

Testing case-insensitive string comparison functions

A function that compares email addresses case-insensitively should treat [email protected], [email protected], and [email protected] as identical. Running alternating case strings through your comparison function is a fast way to verify the function does not depend on any particular case pattern. If the comparison passes for all-lowercase and all-uppercase forms but fails for alternating case, the function is not correctly case-insensitive. This tool produces mixed-case fixtures for your test suite in one click, covering a broader range of character patterns than manual input typically would. For search functionality testing, alternating-case queries verify that the search index normalizes case consistently: a search for "dOcUmEnT" should return the same results as "document" and "DOCUMENT". Generating these test queries from a single source string through this converter ensures consistent test data across your test suite.

A good test suite should include alternating-case input alongside the all-lowercase and all-uppercase forms it already covers. OWASP's guidance on case sensitivity testing calls out case variation as a class of input that exposes inconsistent comparison logic. Adding a few alternating-case fixtures to a regression suite catches the specific failure where a function passes on uniform input but breaks on the staggered pattern. Because the output is deterministic, the same fixture can be reused across every build without recomputing the expected string.

The character position index and its effect on letter patterns

Alternating case behavior depends on the position of each character across the entire string, not the position within each word. Spaces and punctuation count toward the index even though they do not change case themselves. Understanding this index behavior helps you predict the exact output when converting phrases of different lengths. The zero-based indexing model is consistent and deterministic, so the same input always produces the same output regardless of how many times you run it through the converter.

Why identical words produce different casing in different positions

Converting "hello world" produces "hElLo wOrLd". Converting only "world" in isolation produces "wOrLd". The word "world" produces different letter casing in the two contexts because its starting position in the string differs. In "hello world", the "w" falls at position 6 (counting from 0, which is even, so lowercase). As a standalone string, "w" is at position 0 (also even, so lowercase). The first letter of "world" matches in both cases, but the remaining letters shift because they land at different positions in the sequence.

Controlling starting case with pre-positioned strings

If you need the alternating case to start with an uppercase letter rather than lowercase, prepend a single space character before your text before converting, then remove it from the output. The space occupies position 0 (even, lowercase, unchanged), shifting all following characters by one position. Your actual first letter lands at position 1 (odd) and renders uppercase. This is not a built-in option in the tool, but the workaround takes seconds and requires no configuration.

Use this when you need the mocking meme text format for social media captions, Discord messages, informal developer humor, or creative typographic effects.

you should use frameworks
please write tests

yOu sHoUlD UsE FrAmEwOrKs
pLeAsE WrItE TeStS

works on my machine

wOrKs oN My mAcHiNe

For UI copy, the quiet choice is often best. Sentence case capitalizes only the first word and leaves the rest lowercase, which is why button labels, notification messages, tooltip text, and error messages follow it in modern product design.

Yet applying Sentence case manually to a long list of UI strings is tedious. Paste your strings into this tool, and each line converts to Sentence case in one pass.

Where Sentence case is used

Google Material Design¹ recommends Sentence case for button labels, form field labels, dialog body text, and notification messages, while Apple's Human Interface Guidelines² describe sentence case as the more casual choice and ask you to pick one style per element type and use it consistently. Sentence case is also the standard for error messages in most developer frameworks: "Invalid email address" rather than "Invalid Email Address". Furthermore, in technical writing, all body text follows Sentence case, with only headings and proper nouns deviating. Tooltip content and accessibility text (aria-label attributes) should also use Sentence case.

Microsoft's Fluent Design System follows the same rule for all UI controls,³ and the Writing Style Guide from Microsoft explicitly states that Sentence case is the default for all user-facing strings. The UK Government Digital Service⁴ and the US Web Design System⁵ both mandate Sentence case for form labels and error messages, making it the most widely prescribed capitalization style for public-sector digital services. When you apply Sentence case across a product, every notification banner, inline validation message, and empty-state description follows the same quiet capitalization rule, which creates a consistent reading experience that feels approachable rather than shouty. The mechanical simplicity of the rule (first word capitalized, everything else lowercase) makes it the easiest style to enforce in code and the hardest to get wrong during content reviews.

Edge cases: proper nouns, acronyms, and multi-line input

This tool applies a mechanical rule (first word uppercased, rest lowercased) and does not detect proper nouns or brand names. Consequently, "Send to GitHub" converts to "Send to git hub", because the capital H also marks a word boundary, which would need a manual fix. Acronyms like "URL" in "Invalid URL format" also become "Invalid url format". For UI strings containing proper nouns or acronyms, treat this tool as a starting point and review the output before use. Each line in a multi-line input is treated as an independent sentence. Non-English text needs another route: the row keeps only ASCII letters and digits, so accented letters, Cyrillic, Greek and caseless scripts like Chinese or Arabic drop out of the result. Punctuation at the start of a line, such as a bullet character, drops out too, while a leading number becomes the first word, so "1. save changes" comes back as "1 save changes".

Workflow: standardizing a list of error messages

Building on this, a practical workflow: export your error message keys and strings from a localization file (JSON or .po), paste the strings into this tool, and copy the Sentence case output back. You avoid reviewing each message individually for capitalization errors. CapyToolkit converts each line independently, so a file with 200 error messages processes in one pass. Review proper nouns and acronyms after conversion for a clean result. For React projects using react-intl or FormatJS, the converted strings slot directly into your message definitions without further editing. When you add a new language to your application, running the same source strings through this converter gives you a consistent capitalization baseline across all locales before translators begin their work, which reduces review cycles and keeps the source-of-truth strings clean.

Design system guidelines that specify Sentence case for labels

Three of the most-adopted design systems prescribe Sentence case as the default for all interactive and informational copy. Understanding which elements fall under that rule helps you apply it consistently across a product. Applying the rule uniformly prevents the visual inconsistency that creeps in when different authors follow different capitalization habits across a long-lived product with many contributors.

When your team builds across platforms and wants visual parity with OS conventions, Sentence case is the safe default for any label that is not a proper name or brand identifier. The alternative, Title Case, draws attention to every word equally, which creates visual noise in dense interfaces where users need to scan quickly. Sentence case lets the first word anchor the reader's eye and lets the rest of the label recede into the background, which is exactly the behavior you want for secondary text that supports the primary content rather than competing with it.

Material Design and Fluent Design Sentence case rules

Material Design 3 specifies Sentence case for navigation destinations, card titles, dialog titles, and button labels. Microsoft's Fluent Design System follows the same pattern for all UI controls. Both systems reserve Title Case for product names and brand proper nouns only. When your team builds across platforms and wants visual parity with OS conventions, Sentence case is the safe default for any label that is not a proper name or brand identifier.

The practical effect is fewer arguments during design review. When the guideline is simple, authors stop debating whether a given label should be Title Case or Sentence Case and just follow the default. You can apply the same baseline to your strings in CapyToolkit by pasting your labels and converting them, then distributing the output so every component renders the same capitalization style.

Tokens and component libraries that surface Sentence case at the content layer

Design token libraries sometimes surface display text through CMS content fields or structured copy decks. If your component library's <Button> renders whatever string you pass it unchanged, Sentence case enforcement falls entirely to the content author. Batch-converting existing button label strings is faster than reviewing each label by hand, so run every label through Sentence case before pasting them into a token file or CMS. You get a consistent baseline in one pass.

Comparing Sentence case output against proper noun preservation

Sentence case is a mechanical transformation. This tool handles the rule correctly, but some output strings require human review before going into production. Understanding which strings need that review pass is what separates a quick batch conversion from a publish-ready result that reads naturally to your users. When you convert a hundred UI strings at once and every brand name, acronym, and product title in the list arrives in lowercase, a systematic review pass through the output catches the exceptions that the mechanical rule cannot handle on its own.

Brand names, product names, and trademarked strings

Brand names that do not follow standard capitalization rules (iPhone, eBay, GitHub) will be split at their inner capital and lowercased by this tool because they are not the first word in the sentence. A string like "Connect with GitHub" becomes "Connect with git hub" after conversion. Review your output list and restore any brand-capitalized terms before copying to your codebase. Keeping a short list of brand exceptions specific to your product makes the review faster on subsequent passes.

Acronyms in error messages and technical labels

Acronyms like "URL", "API", "ID", and "HTTP" lose their uppercase form when they are not the first word in the sentence. "Invalid API key" becomes "Invalid api key", which looks incorrect to most readers. Review technical strings for acronyms before finalizing the conversion. If your design system mandates all-lowercase for error messages, the tool output may be correct as-is. If the system expects uppercase acronyms preserved, restore them after conversion.

Use this when writing UI button labels, form error messages, notification text, or tooltip strings that should follow Sentence case per your design system.

Save Your Changes
Delete This Item
Confirm Your Email Address
Upgrade Your Plan

Save your changes
Delete this item
Confirm your email address
Upgrade your plan

INVALID_EMAIL_ADDRESS
PASSWORD_TOO_SHORT
ACCESS_DENIED

Invalid email address
Password too short
Access denied

The <title> element defines the document title and affects SEO; page titles can influence search result order and reader click-through¹. Title case is a common convention for English-language work titles: most words are capitalized, while articles, short conjunctions, and short prepositions are often left lowercase unless they start or end the title². Applying it consistently across headings helps long articles and publishing workflows avoid uneven capitalization.

Where Title Case is used

Title Case applies to article headings, page titles, and navigation labels in contexts where every word deserves visual weight. English-language title case commonly capitalizes most words while leaving articles, short conjunctions, and short prepositions lowercase unless they start or end the title³. Google's developer documentation style uses sentence case for document titles, headings, captions, labels, callouts, and table elements⁴, and Apple's interface text guidance allows either title-style or sentence-style capitalization for labels⁵. That means Title Case remains useful for publishing-style headings, while contemporary UI copy often leans toward Sentence case. Academic publications, book covers, and newspaper mastheads still rely on Title Case as the dominant convention, and most style guides (Chicago, APA, MLA) specify it for reference lists and bibliographies. Understanding which convention your project follows prevents inconsistent capitalization across documents that should look like they belong to the same publication.

What this tool does not cover: style-guide-aware title casing

Common title-case rules lowercase short prepositions such as "of", "in", and "at", articles such as "a", "the", and "an", and coordinating conjunctions such as "and", "but", and "or" unless they are the first or last word². Apple defines title-style capitalization similarly for interface labels: capitalize every word except articles, coordinating conjunctions, and prepositions of four or fewer letters, while always capitalizing the first and last word⁵. This tool capitalizes every word regardless of part of speech. Consequently, "The History of Art" becomes "The History Of Art", so review small prepositions and articles after conversion if your style guide requires them.

Workflow: formatting blog headings before publishing

Building on this, a practical use: when you have a list of article headings drafted in lowercase or mixed case, paste them all into this converter and copy the Title Case output. You get consistently capitalized headings for a blog post, documentation page, or changelog. CapyToolkit processes each line independently, so a document with 15 section headings converts in one pass. Review prepositions and articles after conversion if your style guide requires it. For static site generators like Hugo or Astro, the heading in the Markdown frontmatter becomes the page title in the HTML output, the navigation menu, and the Open Graph social preview. Running it through this converter before committing ensures the published heading matches the visible heading on the page, which prevents the common mismatch where a social share shows different capitalization than the article itself.

Title Case in HTML meta tags and structured data markup

HTML meta tags carry title text into search results and social previews without the visual context of a styled page. What appears in the browser tab, the Open Graph preview, and the JSON-LD structured data field should all agree in capitalization style. When these three surfaces show different casing for the same article, readers who click through from a social share perceive a quality mismatch between the preview they saw and the page they landed on.

Open Graph and Twitter Card titles

Open Graph og:title appears in link previews on LinkedIn, Slack, and Discord. When the og:title differs from the visible visible heading in capitalization style, users who arrive from a social share see a mismatch between what attracted them and what the page delivers. Using Title Case for og:title ensures the preview and the landing page look like they belong to the same document. Most CMS platforms populate og:title directly from the page title field, so correcting title case in one place updates both the visible heading and the meta tag simultaneously.

The consistency this creates matters for trust. A reader who clicks a link preview expects the landing page to match what the preview promised, and mismatched capitalization undermines that first impression. You can check your own pages in CapyToolkit by pasting a heading and converting it, then comparing the result against the og:title your CMS emits to confirm the two surfaces agree.

JSON-LD article headlines and schema.org name fields

Schema.org's Article schema specifies a headline property that represents the article title for rich results and Knowledge Graph entries. Google's Structured Data guidelines do not mandate a capitalization style, but they do require the headline to match the visible content on the page. If your schema.org headline reads "How to convert camelCase" while the visible visible heading reads "How To Convert CamelCase", the inconsistency can appear in a structured data audit as a content mismatch. Running both the visible heading and the structured data string through this converter together ensures they stay in sync.

When to prefer Sentence case over Title Case in publishing workflows

Two situations make Sentence case the better choice even in contexts where Title Case might seem appropriate. Knowing which applies to your workflow prevents unnecessary back-and-forth during content reviews. The decision between these two styles affects every heading, label, and notification string in your product, so establishing the rule early prevents a patchwork of inconsistent capitalization that accumulates technical debt across every new feature.

Design systems that prescribe Sentence case for headings

Material Design 3 specifies Sentence case for all display, headline, and title components inside application UIs. Apple's Human Interface Guidelines recommend Sentence case for window titles and all button text. Both systems reserve Title Case for product names and brand proper nouns only. If your product ships on Android, iOS, or the web following either design system, using Title Case for headings inside the app creates a visual inconsistency with platform norms. Running existing Title Case content through a Sentence case converter before implementing a new component library prevents that conflict early.

Long-form documentation where acronyms are dense

Technical documentation with acronyms like "API", "HTTP", or "JSON" can look cluttered in Title Case because each acronym is treated as a word to capitalize. "How To Use The REST API With JSON" reads more naturally as "How to use the REST API with JSON". Sentence case keeps the capitalization of established acronyms unchanged because only the first word is affected. For API references, SDK docs, and developer guides, Sentence case reduces visual noise from densely capitalized section headings.

Use this when a set of article headlines, page titles, navigation labels, or card headings needs the same treatment, since you can capitalize every word in a heading in one pass instead of editing each line by hand before publishing.

how to convert camelCase to snake_case in python

How To Convert Camel Case To Snake Case In Python

getting started with the api
advanced configuration options
frequently asked questions

Getting Started With The Api
Advanced Configuration Options
Frequently Asked Questions