I-paste ang kahit anong text at i-convert ito sa siyam na case format in real time — walang button na iki-click, walang text na ipapadala sa server. Ang pahinang ito ay nagsisilbi ring reference para sa mga naming convention: aling format ang dapat gamitin sa aling language, ang mga panuntunang madalas pagtalunan ng mga style guide, at ang mga naming mistakes na nahuhuli sa code review.

Ang Siyam na Case

Case	Halimbawa	Karaniwang Paggamit
UPPERCASE	HELLO WORLD	Constants, SQL keywords, acronyms, maiikling UI labels
lowercase	hello world	Emails, URLs, CSS values, normalizing input
Title Case	Hello World	Article titles, book titles, pormal na headings
Sentence case	Hello world	Body copy, UI labels, notifications, email subjects
camelCase	helloWorld	JS/TS variables, JSON keys, Java methods, React props
PascalCase	HelloWorld	Class names, TypeScript types, React/Vue components
snake_case	hello_world	Python variables, database columns, Ruby methods
kebab-case	hello-world	CSS classes, HTML attributes, URL slugs, npm packages
CONSTANT_CASE	HELLO_WORLD	Constants at environment variables sa lahat ng languages

Paano Gamitin

1. I-paste o i-type ang text sa input field — ang conversion ay nangyayari in real time.
2. Pumili ng case format mula sa mga radio button.
3. Gamitin ang Mag-upload para mag-load ng .txt file, Burahin para i-reset ang dalawang field, Kopyahin o I-download para kunin ang resulta.

Aling Case ang Dapat Kong Gamitin?

Ang pinakamabilis na sagot base sa konteksto:

Para sa code:

Kung pinapangalanan mo ang…	Gamitin ang
Variable o function sa JS, TS, Java, Swift, Kotlin	camelCase
Variable o function sa Python, Ruby, Rust	snake_case
Class, type, interface, o component (kahit anong language)	PascalCase
Constant o environment variable	CONSTANT_CASE
CSS class o HTML data- attribute	kebab-case
URL path segment o slug	kebab-case
Database column o table name	snake_case
npm o pip package name	kebab-case
JSON object key sa isang REST API	camelCase
Go exported identifier (public)	PascalCase
Go unexported identifier (package-private)	camelCase

Para sa written content:

Konteksto	Gamitin ang	Paalala
News headline, book title, pormal na publication	Title Case	Iba-iba ang panuntunan ng style guides — tingnan ang seksyon sa ibaba
Blog post title, product UI label, app notification	Sentence case	Tumutugma sa kung paano mag-type ng search queries ang mga tao
Button label sa UI na may limitadong space	UPPERCASE	Gamitin nang madalang (use sparingly)
Email subject line	Sentence case	Ang mga subject na puro Title Case ay nauugnay sa mas mababang open rates
Multi-word hashtag	PascalCase	Ang #ContentMarketing ay mas mabilis basahin kaysa sa #contentmarketing

Naming Conventions Ayon sa Programming Language

Language	Variable / Function	Class / Type	Constant	File name
JavaScript	camelCase	PascalCase	CONSTANT_CASE	kebab-case
TypeScript	camelCase	PascalCase	CONSTANT_CASE	kebab-case
Python	snake_case	PascalCase	CONSTANT_CASE	snake_case
Java	camelCase	PascalCase	CONSTANT_CASE	PascalCase
Go	camelCase / PascalCase*	PascalCase	PascalCase	snake_case
Rust	snake_case	PascalCase	CONSTANT_CASE	snake_case
Ruby	snake_case	PascalCase	CONSTANT_CASE	snake_case
C#	camelCase / PascalCase†	PascalCase	PascalCase	PascalCase
PHP	camelCase	PascalCase	CONSTANT_CASE	snake_case
Swift	camelCase	PascalCase	camelCase‡	PascalCase
SQL columns	snake_case	—	—	—
CSS classes	kebab-case	—	—	—
URL slugs	kebab-case	—	—	—
npm / pip packages	kebab-case	—	—	—
ENV variables	—	—	CONSTANT_CASE	—
JSON keys (REST)	camelCase	—	—	—

* Go: kinokontrol ng capitalization ang export visibility. PascalCase = exported (public); camelCase = unexported (package-private). Ito ay pinapatupad ng compiler, hindi lang ito convention.

† C#: ang local variables at parameters ay gumagamit ng camelCase; ang methods, properties, at public fields ay gumagamit ng PascalCase.

‡ Swift: ang constants ay gumagamit ng camelCase — ang let maxRetries = 3 ay idiomatic; ang let MAX_RETRIES = 3 ay hindi.

Kailan Dapat Gamitin ang Bawat Case

camelCase

Ang camelCase ay lumabas mula sa SIMULA at sa mga unang object-oriented language noong dekada 1960, naabot nito ang mainstream adoption sa pamamagitan ng Java (1995), at kumalat sa JavaScript, TypeScript, Swift, at Kotlin. Ang patakaran ay simple: ang unang salita ay nananatiling lowercase lahat, at bawat susunod na salita ay nagsisimula sa capital letter, nang walang anumang separator character.

Ang case na ito ay nangingibabaw sa anumang ecosystem kung saan ang Java ang nagtakda ng mga unang convention. Ang Node.js core APIs (readFile, createServer, writeFileSync), React event props (onClick, onChange, defaultValue), at REST JSON keys (userId, createdAt, isActive) ay sumusunod dito. Pinapatupad ito ng ESLint sa mga JavaScript project sa pamamagitan ng built-in na camelcase rule.

// React
const [isLoading, setIsLoading] = useState(false);
const handleSubmit = (event) => { ... };

// Node.js
fs.readFile(filePath, 'utf8', callback);
http.createServer(requestListener);

Kailan hindi dapat gamitin: Huwag na huwag sa mga URL path — maraming server ang case-insensitive kaya ang UserOrders at userorders ay nagiging iisang route. Huwag na huwag sa mga Python o Ruby file (parehong bina-flag ito ng PEP 8 at ng Ruby Style Guide). Huwag na huwag para sa mga class name sa kahit anong language — teritoryo iyon ng PascalCase.

PascalCase

Nakuha ng PascalCase ang pangalan nito sa wikang Pascal (Niklaus Wirth, 1970), bagaman ang mga tool ng Borland at Delphi ang nagpakalat nito bilang pamantayan sa pagpapangalan ng class noong dekada 1990. Bawat salita — pati na rin ang unang salita — ay nagsisimula sa capital letter. Ang nag-iisang pagkakaibang iyon mula sa camelCase ay may dalang mahalagang semantic meaning: Sinasabi ng PascalCase na “ito ay isang bagay na ini-instantiate mo o isang type na iyong nire-reference,” hindi “ito ay isang aksyon na tinatawag mo.”

Ang pattern na ito ay pangkalahatang pamantayan para sa mga class name sa lahat ng malalaking OOP language. Sa TypeScript, umaabot ito sa interfaces at type aliases. Sa React at Vue, ito ay required para sa component names — ginagamit ng framework ang capitalization upang makilala ang user-defined components (UserProfile) mula sa mga HTML element (div, input). Sa C#, sakop din ng PascalCase ang mga method at public properties bukod pa sa class names.

// React component
export default function UserProfileCard({ userId }) { ... }

// TypeScript
interface ApiResponse<T> {
  data: T;
  totalCount: number;
  nextCursor: string | null;
}

// Python
class DatabaseConnection:
    def __init__(self, url: str) -> None: ...

Kailan hindi dapat gamitin: Huwag na huwag para sa mga variable o regular na function sa JavaScript, TypeScript, o Python. Ang isang PascalCase na function sa JS ay nagpapahiwatig na ito ay isang constructor na nilalayong tawagin gamit ang new — ang paggamit nito para sa isang simpleng utility function ay nakakalito sa ibang developer at maaaring mag-trigger ng lint warnings.

snake_case

Ang snake_case ay nag-ugat sa mga pangalan ng C library function (printf, fopen, strcmp) at Unix shell scripting. Pormal itong ginawang pamantayan ng PEP 8 ng Python (na isinulat ni Guido van Rossum noong 2001) para sa wika dahil sa rasong ito: ang mga_salitang_pinaghiwalay_ng_underscore ay mas nababasa gaya ng English prose kaysa sa masikip na camelCase, kaya’t ang code ay nagiging mas madaling intindihin para sa mga domain expert na hindi primarily mga programmer.

Ito ang universal na pamantayan para sa relational database identifiers — ang SQL ay case-insensitive by default, kaya ang UserProfile at userprofile ay iisang column, at ginagawang madaling basahin ng snake_case ang mga column nang hindi nakadepende sa capitalization. Ang ORM ng Django, Rails migrations, at halos lahat ng database migration tool ay nag-generate ng mga snake_case na pangalan ng column.

# Django model
class UserProfile(models.Model):
    first_name = models.CharField(max_length=100)
    created_at = models.DateTimeField(auto_now_add=True)
    is_active = models.BooleanField(default=True)

def get_user_by_id(user_id: int) -> UserProfile:
    return UserProfile.objects.get(pk=user_id)

Kailan hindi dapat gamitin: Huwag na huwag sa mga URL path — hindi masyadong nakikita ang mga underscore kapag naka-underline ang mga URL sa mga browser at maaaring alisin ng ilang link processor. Ang snake_case ay technically valid sa mga JavaScript identifier ngunit nilalabag nito ang camelcase rule ng ESLint at nagpapahiwatig sa bawat JS developer na ang sumulat nito ay nag-iisip tulad ng isang Python dev.

kebab-case

Ang kebab-case ay binubuo ng maliliit na salita (lowercase words) na pinagdudugtong ng mga gitling (hyphen). In-adopt ito ng CSS bilang pamantayan para sa lahat ng pangalan ng property — background-color, font-size, border-radius, flex-direction — at ang convention ay kumalat sa mga HTML attribute, URL slug, at npm packages. Ang gitling ay angkop na angkop para sa mga web context dahil kailanman ay hindi ito naging valid na identifier character sa karamihan ng mga programming language, na siya ring eksaktong dahilan kung bakit hindi ito maaaring magamit para sa mga code variable.

Ang kaso ng SEO para sa kebab-case URLs ay matatag na napatunayan: Itinuturing ng Google ang mga gitling bilang word separators sa mga URL ngunit hindi nito tinatrato ang mga underscore sa katulad na paraan. Ang isang URL na gaya ng /blog/user-profile-guide ay ini-index kasama ng “user,” “profile,” at “guide” bilang magkakahiwalay na searchable terms. Ang /blog/user_profile_guide ay ini-index bilang iisang token lamang. Para sa anumang pampublikong URL, ang kebab-case ang tanging pagpipilian na may benepisyo sa SEO. Ilang beses nang kinumpirma ni John Mueller ng Google ang pagkakaibang ito sa mga pampublikong Q&A.

/* CSS */
.nav-item { ... }
.card-header { ... }
.btn-primary { ... }

<!-- HTML -->
<div data-user-id="123" data-tracking-event="page-view">

/* npm */
react-router, tailwind-css, lodash, date-fns

Kailan hindi dapat gamitin: Huwag na huwag para sa mga code variable o function. Sa bawat C-style language, ang gitling ay ang subtraction operator — ang my-variable ay ipa-parse bilang my minus variable.

CONSTANT_CASE

Ang CONSTANT_CASE ay nagmula sa mga C preprocessor macro noong dekada 1970 (#define MAX_BUFFER_SIZE 1024). Ang pattern na puro-malalaking-titik-na-may-underscore (all-caps-with-underscores) ay naging unibersal na senyales para sa “ang halagang ito ay nakatakda (fixed) sa compile time o configuration time at hindi dapat magbago sa runtime.” In-adopt ng bawat malaking language ang pattern; pinalawig ito ng mga .env file at shell script sa deployment configuration.

Ang pagiging visually malakas ng ALL_CAPS ay nagsisilbing isang tunay na function: ipinapaalam nito agad sa mambabasa na ito ay configuration, hindi logic — isang nakapirming boundary condition, hindi isang computed na value. Ang senyales na iyon ay karapat-dapat panatilihin, kaya naman ang paggamit ng CONSTANT_CASE para sa mga nababagong halaga (mutable values) o pangalan ng function ay isang tunay na pagkakamali (tingnan ang seksyon sa ibaba).

# Environment variables (.env)
DATABASE_URL=postgresql://localhost/mydb
STRIPE_API_KEY=sk_live_...
MAX_UPLOAD_SIZE_MB=10
JWT_SECRET_KEY=...

// JavaScript module constants
const MAX_RETRIES = 3;
const API_BASE_URL = 'https://api.example.com/v1';
const DEFAULT_TIMEOUT_MS = 5000;

Kailan hindi dapat gamitin: Huwag na huwag para sa mga function, method, o variable na nagbabago sa runtime. Huwag na huwag para sa mga class name. Partikular sa Swift, ang mga constant ay gumagamit ng camelCase — ang let maxRetries = 3 ay idiomatic; ang CONSTANT_CASE pattern ay hindi ginagamit sa Swift code.

Mga Karaniwang Naming Mistakes

Ito ang mga error na lumilitaw sa code review, napa-flag ng mga linter, at nagpapahirap basahin ang codebase para sa lahat ng susunod na hahawak nito.

Paghahalo ng mga convention sa iisang project

Ito ang pinakanakakapinsalang naming mistake. Ang isang codebase kung saan magkasama ang getUserById at get_order_history ay pamumwersa sa mga mambabasa na mag-context-switch sa bawat function call — hindi nila mahulaan kung ang susunod na function ay camelCase ba o snake_case. Ang isang project na palaging gumagamit ng “maling” convention para sa ecosystem nito ay mas nababasa pa rin kaysa sa isa na naghahalo ng mga “tamang” convention. Pumili ng isang convention bawat konteksto at ipatupad ito gamit ang isang linter simula sa unang araw.

snake_case sa mga JavaScript variable name

Ang const user_profile = {} ay valid na JavaScript — walang pakialam ang runtime. Ngunit sinasabi nito sa bawat JavaScript developer na magbabasa ng code na ang sumulat ay nanggaling sa Python o Ruby background. Bina-flag ito ng built-in na camelcase rule ng ESLint. Kung ang team niyo ay nagtatrabaho sa parehong JS at Python files, karaniwan ang cross-contamination na ito; labanan ito. Ang snake_case ay para sa .py files, ang camelCase ay para sa .js at .ts files.

camelCase o snake_case sa mga URL path

Parehong mali ang /api/userOrders at /api/user_orders. Ang camelCase sa mga URL ay may panganib ng case-sensitivity bugs — ang Apache sa Windows ay case-insensitive, kaya ang /api/UserOrders at /api/userorders ay iisang route, ngunit hindi ganyan ang /api/userOrders sa isang Linux server. Nawawalan ng silbi bilang word-separator para sa mga search engine ang mga underscore sa mga URL (tingnan ang seksyon ng kebab-case sa itaas). Ang tamang porma ay /api/user-orders para sa bawat public-facing URL.

CONSTANT_CASE para sa mga hindi constant

Gumagamit ng visual signal ang function GET_USER_BY_ID(id) {} na nangangahulugang “hinding-hindi magbabago ang halagang ito.” Ang pag-apply nito sa isang function, isang computed property, o isang mutable na variable ay nakakalito sa sinumang developer na magbabasa ng code kalaunan. I-reserve lang ang CONSTANT_CASE para sa mga halagang isini-set kapag nag-startup at hindi na muling inia-assign — module-level constants, environment variable reads, at compile-time configuration.

PascalCase para sa utility functions sa JavaScript

Ang function GetUserById(id) {} ay mukhang isang constructor sa JavaScript. Ang convention na PascalCase = “tawagin gamit ang new” ay malalim na nakabaon sa ecosystem. Ang isang PascalCase na function na hindi naman constructor ay makakalito sa mga mambabasa at maaaring mag-trigger ng new-cap rule ng ESLint. Gamitin ang camelCase para sa lahat ng function at method; i-reserve ang PascalCase para lang sa mga class, type, at React components.

Mga pangalan na nangangailangan ng komento para maipaliwanag

usrPrf, ord, cfg, tmp2. Ang pagiging maikli (brevity) ay mabuti hanggang sa lumikha ito ng kalituhan — ang ord ay maaaring order, ordinal, o ordinary. Ang mga modern editor ay may inilaan na autocomplete; walang totoong keystroke cost sa userProfile. Ang test: kung ang pangalan ay nangangailangan ng inline comment para ipaliwanag kung ano ito, palitan mo ang pangalan nito.

Pag-handle ng mga Acronym sa Variable Names

Ang mga acronym tulad ng API, HTTP, URL, at ID ay lumilikha ng tunay na ambiguity sa camelCase at PascalCase. Dapat mo bang isulat na myAPIKey o myApiKey?

Ituring ang mga acronym bilang words (modern, inirerekomenda para sa mga bagong project): myApiKey, HttpRequest, parseUrl, getUserById. Ito ang approach sa standard library ng TypeScript at sa Java Style Guide ng Google. Mas madali itong i-scan at naiiwasan nito ang problema ng magkakatabing acronym — ang parseHtmlToXml ay agad na nababasa samantalang ang parseHTMLtoXML ay nangangailangan pa ng pangalawang tingin.

Panatilihin ang acronym caps (tradisyonal): myAPIKey, HTTPRequest, parseURL. Mas karaniwan ito sa mas matatandang Java at C# codebases. Lumilikha ng mga problema sa readability kapag ang dalawang acronym ay nagkasama.

Para sa snake_case at CONSTANT_CASE, nawawala ang tanong na ito — ang api_key, http_request, API_KEY, HTTP_HOST ay lahat malinaw (unambiguous) anuman ang approach na iyong sinusunod.

Ang espesyal na rule ng Go: ang two-letter acronyms ay pinapanatiling fully capitalized (ID, DB, IP); ang mas mahahabang acronym ay tinuturing bilang mga salita (Http, Url, Api). Ito ay nakadokumento sa Go Code Review Comments guide.

Ang tanging panuntunan na mahalaga: pumili ng isang approach at i-apply ito nang consistent sa buong codebase. Ang paghahalo ng myApiKey at myAPIKey sa iisang project ay mas malala kaysa sa pumili ka lang ng isa.

Title Case: Rules Ayon sa Style Guide

Kina-capitalize ng Title Case ang ilang partikular na salita sa isang heading o title. Apat na pangunahing style guide ang nagtatakda kung aling mga salita ang dapat i-capitalize — at sila ay hindi nagkakasundo sa mga edge case.

Panuntunan	AP Style	APA Style	Chicago Style	MLA Style
I-capitalize ang una at huling salita	✓	✓	✓	✓
I-capitalize ang mga noun, verb, adjective, adverb	✓	✓	✓	✓
Maikling prepositions (in, on, at, by, of, up)	Lowercase ≤3 letters	Lowercase ≤3 letters	Lowercase	Lowercase LAHAT
Coordinating conjunctions (and, but, or, nor)	Lowercase	Lowercase	Lowercase	Lowercase
Articles (a, an, the)	Lowercase	Lowercase	Lowercase	Lowercase
”to” bilang infinitive marker	I-capitalize	I-capitalize	I-capitalize	I-capitalize
”to” bilang preposition	Lowercase	Lowercase	Lowercase	Lowercase
Maiikling verbs (is, are, was)	I-capitalize	I-capitalize	I-capitalize	I-capitalize

Ang parehong pamagat sa lahat ng apat na istilo:

“A Guide to Writing for the Web and Social Media”

Lahat ng apat ay nagkakasundo rito. Lumilitaw ang mga hindi pagkakasundo sa mas mahahabang preposition (“about,” “between,” “without”) at mga compound title na pinagsasama ng colon.

Mga salitang palaging lowercase sa lahat ng apat na istilo (maliban kung nagbubukas o nagsasara ng title): a, an, the, and, but, or, nor, for, so, yet, as, at, by, in, of, on, to (preposition), up, via.

Ang converter na ito ay kina-capitalize ang bawat salita — ang pinakakaraniwang general-purpose na gawi. Para sa mahigpit na pagsunod sa AP, APA, Chicago, o MLA, gamitin ang tool na ito para sa first pass at gumawa ng manu-manong mga pagwawasto para sa maiikling salita.

Pre-filling via URL Parameters

Maaari mong i-pre-load ang input text at case type gamit ang URL:

https://www.uprek.com/tl/tools/case-converter?input=Hello+World&case=snake

Mga available na ?case= value: upper, lower, title, sentence, camel, pascal, snake, kebab, constant.

Privacy

Lahat ng conversion ay tumatakbo sa iyong browser gamit ang native JavaScript — String.toUpperCase(), String.toLowerCase(), String.replace(), at TextEncoder. Ang iyong text ay hindi kailanman ipinapadala sa aming mga server, hindi kailanman nilo-log, at hindi kailanman sino-store. Para i-verify: buksan ang developer tools ng browser mo, pumunta sa Network tab, i-paste ang text sa tool, at lumipat ng mga format — wala kang makikitang outbound network requests.

Mga Madalas na Itanong (FAQ)

Talaan ng mga Pagbabago