Dán bất kỳ văn bản nào và chuyển đổi sang chín định dạng chữ hoa chữ thường (case) trong thời gian thực — không cần nhấp nút, không có dữ liệu nào được gửi đến máy chủ. Trang này cũng đóng vai trò như một tài liệu tham khảo về quy ước đặt tên: định dạng nào dùng cho ngôn ngữ nào, các quy tắc mà mỗi hướng dẫn văn phong (style guide) thực sự bất đồng, và những lỗi sai thường bị phát hiện trong quá trình đánh giá mã nguồn (code review).

Chín Định Dạng Chữ Hoa Chữ Thường

Case	Ví dụ	Trường hợp sử dụng tiêu biểu
UPPERCASE	HELLO WORLD	Hằng số, từ khóa SQL, từ viết tắt, nhãn UI ngắn
lowercase	hello world	Email, URL, giá trị CSS, chuẩn hóa đầu vào
Title Case	Hello World	Tiêu đề bài viết, tựa sách, đề mục trang trọng
Sentence case	Hello world	Nội dung văn bản, nhãn UI, thông báo, tiêu đề email
camelCase	helloWorld	Biến JS/TS, khóa JSON, phương thức Java, props React
PascalCase	HelloWorld	Tên class, kiểu TypeScript, component React/Vue
snake_case	hello_world	Biến Python, cột cơ sở dữ liệu, phương thức Ruby
kebab-case	hello-world	Class CSS, thuộc tính HTML, URL slug, gói npm
CONSTANT_CASE	HELLO_WORLD	Hằng số và biến môi trường trong mọi ngôn ngữ

Cách Sử Dụng

1. Dán hoặc nhập văn bản vào trường đầu vào — quá trình chuyển đổi diễn ra trong thời gian thực.
2. Chọn một định dạng từ các nút radio.
3. Dùng Tải lên để tải tệp .txt, Xóa để đặt lại cả hai trường, Sao chép hoặc Tải xuống để lấy kết quả.

Tôi Nên Sử Dụng Định Dạng Nào?

Câu trả lời nhanh nhất dựa theo ngữ cảnh:

Dành cho mã nguồn (code):

Nếu bạn đang đặt tên cho…	Sử dụng
Biến hoặc hàm trong JS, TS, Java, Swift, Kotlin	camelCase
Biến hoặc hàm trong Python, Ruby, Rust	snake_case
Class, type, interface, hoặc component (bất kỳ ngôn ngữ nào)	PascalCase
Hằng số hoặc biến môi trường	CONSTANT_CASE
Class CSS hoặc thuộc tính data- trong HTML	kebab-case
Đoạn đường dẫn URL hoặc slug	kebab-case
Cột cơ sở dữ liệu hoặc tên bảng	snake_case
Tên gói npm hoặc pip	kebab-case
Khóa của đối tượng JSON trong REST API	camelCase
Định danh được export trong Go (public)	PascalCase
Định danh không được export trong Go (package-private)	camelCase

Dành cho nội dung văn bản:

Ngữ cảnh	Sử dụng	Ghi chú
Tiêu đề tin tức, tựa sách, ấn phẩm trang trọng	Title Case	Các quy tắc trong hướng dẫn văn phong có sự khác biệt — xem phần bên dưới
Tiêu đề bài viết blog, nhãn UI sản phẩm, thông báo ứng dụng	Sentence case	Phù hợp với cách mọi người gõ các truy vấn tìm kiếm
Nhãn nút bấm trong giao diện giới hạn không gian	UPPERCASE	Sử dụng một cách hạn chế
Tiêu đề email	Sentence case	Tiêu đề viết hoàn toàn bằng Title Case thường có tỷ lệ mở thấp hơn
Hashtag có nhiều từ	PascalCase	#ContentMarketing dễ đọc lướt hơn #contentmarketing

Quy Ước Đặt Tên Theo Ngôn Ngữ Lập Trình

Ngôn ngữ	Biến / Hàm	Class / Kiểu	Hằng số	Tên tệp
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
Cột SQL	snake_case	—	—	—
Class CSS	kebab-case	—	—	—
URL slug	kebab-case	—	—	—
Gói npm / pip	kebab-case	—	—	—
Biến ENV	—	—	CONSTANT_CASE	—
Khóa JSON (REST)	camelCase	—	—	—

* Go: Việc viết hoa kiểm soát khả năng hiển thị (export). PascalCase = được export (public); camelCase = không được export (package-private). Điều này được trình biên dịch bắt buộc chứ không chỉ là quy ước.

† C#: Các biến cục bộ và tham số sử dụng camelCase; các phương thức, thuộc tính và trường công khai sử dụng PascalCase.

‡ Swift: Hằng số sử dụng camelCase — let maxRetries = 3 là cách viết chuẩn (idiomatic); let MAX_RETRIES = 3 thì không.

Khi Nào Nên Sử Dụng Từng Định Dạng

camelCase

camelCase xuất hiện từ ngôn ngữ SIMULA và các ngôn ngữ hướng đối tượng sơ khai vào những năm 1960, được áp dụng rộng rãi qua Java (1995), và lan rộng sang JavaScript, TypeScript, Swift, cũng như Kotlin. Quy tắc rất đơn giản: từ đầu tiên giữ nguyên chữ thường hoàn toàn, mọi từ tiếp theo bắt đầu bằng một chữ in hoa, không có ký tự phân cách.

Định dạng này chiếm ưu thế trong bất kỳ hệ sinh thái nào mà Java đã thiết lập các quy ước ban đầu. Các API cốt lõi của Node.js (readFile, createServer, writeFileSync), các prop sự kiện của React (onClick, onChange, defaultValue), và các khóa JSON của REST (userId, createdAt, isActive) đều tuân theo quy tắc này. ESLint bắt buộc điều này trong các dự án JavaScript thông qua quy tắc camelcase được tích hợp sẵn.

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

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

Khi nào không nên sử dụng: Tuyệt đối không dùng trong đường dẫn URL — nhiều máy chủ không phân biệt chữ hoa chữ thường và UserOrders với userorders sẽ trở thành cùng một route. Tuyệt đối không dùng trong các tệp Python hoặc Ruby (cả PEP 8 và Ruby Style Guide đều cảnh báo điều này). Tuyệt đối không dùng cho tên class ở bất kỳ ngôn ngữ nào — đó là lãnh địa của PascalCase.

PascalCase

PascalCase lấy tên từ ngôn ngữ Pascal (Niklaus Wirth, 1970), mặc dù các công cụ của Borland và Delphi đã phổ biến nó như một tiêu chuẩn đặt tên class vào những năm 1990. Mọi từ — bao gồm cả từ đầu tiên — đều bắt đầu bằng chữ in hoa. Khác biệt duy nhất đó so với camelCase mang một sức nặng về mặt ngữ nghĩa: PascalCase nói lên rằng “đây là một thực thể bạn khởi tạo hoặc một kiểu bạn tham chiếu”, chứ không phải “đây là một hành động bạn gọi”.

Mẫu này là tiêu chuẩn phổ quát cho tên class trong tất cả các ngôn ngữ OOP chính. Trong TypeScript, nó mở rộng sang interface và type alias. Trong React và Vue, nó là bắt buộc cho tên component — framework sử dụng việc viết hoa để phân biệt các component do người dùng định nghĩa (UserProfile) với các phần tử HTML (div, input). Trong C#, PascalCase bao hàm cả các phương thức và thuộc tính công khai (public) ngoài tên class.

// 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: ...

Khi nào không nên sử dụng: Tuyệt đối không dùng cho biến hoặc hàm thông thường trong JavaScript, TypeScript, hay Python. Một hàm PascalCase trong JS ngụ ý rằng nó là một hàm tạo (constructor) dùng để gọi với từ khóa new — việc sử dụng nó cho một hàm tiện ích thông thường sẽ gây hiểu lầm cho các lập trình viên khác và có thể kích hoạt các cảnh báo lint.

snake_case

snake_case có nguồn gốc từ các tên hàm trong thư viện C (printf, fopen, strcmp) và lập trình shell Unix. PEP 8 của Python (do Guido van Rossum viết năm 2001) đã chính thức hóa định dạng này cho ngôn ngữ với lý do: cac_tu_duoc_phan_tach_bang_dau_gach_duoi đọc giống văn xuôi tiếng Anh hơn là camelCase bị nén lại, giúp code dễ tiếp cận hơn với những chuyên gia trong ngành không chủ yếu là lập trình viên.

Đây là tiêu chuẩn chung cho các định danh cơ sở dữ liệu quan hệ — SQL mặc định không phân biệt chữ hoa chữ thường, vì vậy UserProfile và userprofile là cùng một cột, và snake_case giúp các cột dễ đọc mà không phụ thuộc vào việc viết hoa. ORM của Django, các migration của Rails và gần như mọi công cụ migration cơ sở dữ liệu đều tạo ra tên cột dạng snake_case.

# 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)

Khi nào không nên sử dụng: Tuyệt đối không dùng trong đường dẫn URL — dấu gạch dưới không hiển thị rõ khi URL được gạch chân trong trình duyệt và có thể bị loại bỏ bởi một số bộ xử lý liên kết. snake_case về mặt kỹ thuật là hợp lệ trong các định danh JavaScript nhưng nó vi phạm quy tắc camelcase của ESLint và ra dấu cho mọi lập trình viên JS rằng tác giả đang tư duy theo kiểu Python.

kebab-case

kebab-case được định nghĩa bởi các từ viết thường nối với nhau bằng dấu gạch ngang. CSS đã áp dụng nó làm tiêu chuẩn cho tất cả tên thuộc tính — background-color, font-size, border-radius, flex-direction — và quy ước này lan sang các thuộc tính HTML, slug URL và các gói npm. Dấu gạch ngang đặc biệt phù hợp với bối cảnh web vì nó không bao giờ là ký tự định danh hợp lệ trong hầu hết các ngôn ngữ lập trình, đó cũng chính xác là lý do tại sao nó không thể được sử dụng cho biến trong code.

Lợi ích SEO đối với URL dạng kebab-case đã được xác lập rõ ràng: Google coi dấu gạch ngang là dấu phân cách từ trong URL nhưng không xử lý dấu gạch dưới theo cách tương tự. Một URL như /blog/user-profile-guide được lập chỉ mục (index) với “user”, “profile”, và “guide” như những từ khóa tìm kiếm riêng biệt. /blog/user_profile_guide lại được lập chỉ mục như một token duy nhất. Đối với bất kỳ URL nào công khai ra bên ngoài, kebab-case là lựa chọn duy nhất mang lại lợi ích cho SEO. John Mueller của Google đã xác nhận sự khác biệt này nhiều lần trong các phiên hỏi đáp công khai.

/* 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

Khi nào không nên sử dụng: Tuyệt đối không dùng cho biến hoặc hàm trong code. Trong mọi ngôn ngữ mang phong cách C, dấu gạch ngang là toán tử trừ — my-variable sẽ được phân tích cú pháp là my trừ đi variable.

CONSTANT_CASE

CONSTANT_CASE bắt nguồn từ các macro tiền xử lý C vào những năm 1970 (#define MAX_BUFFER_SIZE 1024). Mẫu toàn-chữ-hoa-với-dấu-gạch-duới đã trở thành tín hiệu chung cho “giá trị này được cố định vào thời điểm biên dịch (compile time) hoặc cấu hình (configuration time) và không được thay đổi lúc chạy (runtime)”. Mọi ngôn ngữ lớn đều áp dụng mẫu này; các tệp .env và shell script đã mở rộng nó sang cấu hình triển khai.

Sự nổi bật về mặt thị giác của ALL_CAPS phục vụ một chức năng thực tế: nó cho người đọc biết ngay từ cái nhìn đầu tiên rằng đây là cấu hình, chứ không phải logic — một điều kiện biên cố định, không phải giá trị được tính toán. Tín hiệu đó đáng được giữ gìn, đó là lý do tại sao việc sử dụng CONSTANT_CASE cho các giá trị có thể thay đổi (mutable) hoặc tên hàm là một sai lầm thực sự (xem phần bên dưới).

# 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;

Khi nào không nên sử dụng: Tuyệt đối không dùng cho các hàm, phương thức hoặc biến thay đổi lúc chạy. Tuyệt đối không dùng cho tên class. Cụ thể trong Swift, các hằng số sử dụng camelCase — let maxRetries = 3 là cách viết chuẩn; mẫu CONSTANT_CASE không được sử dụng trong mã nguồn Swift.

Các Lỗi Đặt Tên Thường Gặp

Những lỗi này thường xuất hiện trong quá trình code review, bị linter gắn cờ, và làm cho codebase trở nên khó đọc hơn đối với bất kỳ ai tiếp quản sau này.

Pha trộn các quy ước trong cùng một dự án

Lỗi đặt tên gây hại nhất. Một codebase nơi getUserById và get_order_history cùng tồn tại buộc người đọc phải chuyển đổi ngữ cảnh liên tục trên mỗi lời gọi hàm — họ không thể đoán trước liệu hàm tiếp theo sẽ là camelCase hay snake_case. Một dự án nhất quán sử dụng quy ước “sai” cho hệ sinh thái của nó vẫn dễ đọc hơn một dự án pha trộn những quy ước “đúng”. Hãy chọn một quy ước cho mỗi ngữ cảnh và bắt buộc áp dụng nó bằng linter ngay từ ngày đầu tiên.

snake_case trong tên biến JavaScript

const user_profile = {} là mã JavaScript hợp lệ — runtime không bận tâm. Nhưng nó báo hiệu cho mọi lập trình viên JavaScript khi đọc code rằng tác giả đến từ nền tảng Python hoặc Ruby. Quy tắc camelcase tích hợp sẵn của ESLint sẽ cảnh báo điều này. Nếu nhóm của bạn làm việc trên cả tệp JS và Python, sự lây nhiễm chéo này rất phổ biến; hãy cố gắng cưỡng lại nó. snake_case nằm ở các tệp .py, còn camelCase nằm ở các tệp .js và .ts.

camelCase hoặc snake_case trong đường dẫn URL

/api/userOrders và /api/user_orders đều sai. Dùng camelCase trong URL có nguy cơ gây lỗi phân biệt chữ hoa chữ thường — Apache trên Windows không phân biệt chữ hoa chữ thường, nên /api/UserOrders và /api/userorders là cùng một route, nhưng /api/userOrders trên máy chủ Linux thì không phải vậy. Dấu gạch dưới trong URL làm mất đi ý nghĩa phân tách từ đối với các công cụ tìm kiếm (xem phần kebab-case ở trên). Dạng đúng là /api/user-orders cho mọi URL công khai hướng đến người dùng.

CONSTANT_CASE cho những thứ không phải hằng số

function GET_USER_BY_ID(id) {} sử dụng một dấu hiệu trực quan có nghĩa là “giá trị này không bao giờ thay đổi”. Việc áp dụng nó cho một hàm, một thuộc tính được tính toán (computed property), hoặc một biến có thể thay đổi sẽ gây hiểu lầm cho mọi lập trình viên đọc code sau này. Hãy dành riêng CONSTANT_CASE nghiêm ngặt cho các giá trị được thiết lập lúc khởi động và không bao giờ được gán lại — các hằng số cấp module, việc đọc biến môi trường, và cấu hình thời gian biên dịch.

PascalCase cho các hàm tiện ích trong JavaScript

function GetUserById(id) {} trông giống như một hàm tạo trong JavaScript. Quy ước PascalCase = “gọi bằng new” đã ăn sâu vào hệ sinh thái này. Một hàm PascalCase không phải là hàm tạo sẽ gây nhầm lẫn cho người đọc và có thể kích hoạt quy tắc new-cap của ESLint. Sử dụng camelCase cho tất cả các hàm và phương thức; chỉ dành riêng PascalCase cho class, type, và component React.

Những cái tên yêu cầu phải có comment để giải thích

usrPrf, ord, cfg, tmp2. Sự ngắn gọn là một đức tính tốt cho đến khi nó tạo ra sự mơ hồ — ord có thể là order, ordinal, hoặc ordinary. Các trình soạn thảo hiện đại đều cung cấp tính năng tự động hoàn thành (autocomplete); không hề tốn thêm thời gian gõ phím thực sự nào cho userProfile. Bài kiểm tra là: nếu cái tên yêu cầu một comment nội tuyến để giải thích nó đang ám chỉ điều gì, hãy đổi tên nó đi.

Xử Lý Các Từ Viết Tắt Trong Tên Biến

Các từ viết tắt (như API, HTTP, URL, và ID) tạo ra sự mơ hồ thực sự trong camelCase và PascalCase. Bạn nên viết myAPIKey hay myApiKey?

Coi từ viết tắt như các từ thông thường (hiện đại, khuyên dùng cho dự án mới): myApiKey, HttpRequest, parseUrl, getUserById. Đây là cách tiếp cận trong thư viện chuẩn của TypeScript và Java Style Guide của Google. Nó dễ đọc lướt hơn và tránh được vấn đề các từ viết tắt nằm cạnh nhau — parseHtmlToXml ngay lập tức có thể đọc được trong khi parseHTMLtoXML yêu cầu phải nhìn lại lần hai.

Giữ nguyên chữ viết hoa của từ viết tắt (truyền thống): myAPIKey, HTTPRequest, parseURL. Phổ biến hơn trong các codebase Java và C# cũ. Gây ra các vấn đề về khả năng đọc khi hai từ viết tắt xuất hiện cùng nhau.

Đối với snake_case và CONSTANT_CASE, câu hỏi này biến mất — api_key, http_request, API_KEY, HTTP_HOST đều không có sự mơ hồ bất kể bạn theo trường phái nào.

Quy tắc đặc biệt của Go: Các từ viết tắt có hai chữ cái giữ nguyên viết hoa hoàn toàn (ID, DB, IP); các từ viết tắt dài hơn được coi như các từ thông thường (Http, Url, Api). Điều này được ghi nhận trong hướng dẫn Go Code Review Comments.

Quy tắc duy nhất quan trọng: chọn một phương pháp tiếp cận và áp dụng nó nhất quán trên toàn bộ codebase. Việc trộn lẫn myApiKey và myAPIKey trong cùng một dự án tồi tệ hơn là chỉ chọn một trong hai.

Title Case: Quy Tắc Theo Các Hướng Dẫn Văn Phong

Title Case viết hoa các từ nhất định trong một tiêu đề hoặc đề mục. Bốn hướng dẫn văn phong (style guide) lớn đều định nghĩa những từ nào cần viết hoa — và chúng không thống nhất với nhau ở những trường hợp ngoại lệ.

Quy tắc	AP Style	APA Style	Chicago Style	MLA Style
Viết hoa từ đầu tiên và cuối cùng	✓	✓	✓	✓
Viết hoa danh từ, động từ, tính từ, trạng từ	✓	✓	✓	✓
Giới từ ngắn (in, on, at, by, of, up)	Viết thường ≤3 chữ cái	Viết thường ≤3 chữ cái	Viết thường	Viết thường TẤT CẢ
Liên từ kết hợp (and, but, or, nor)	Viết thường	Viết thường	Viết thường	Viết thường
Mạo từ (a, an, the)	Viết thường	Viết thường	Viết thường	Viết thường
”to” như một dấu hiệu của động từ nguyên thể	Viết hoa	Viết hoa	Viết hoa	Viết hoa
”to” như một giới từ	Viết thường	Viết thường	Viết thường	Viết thường
Động từ ngắn (is, are, was)	Viết hoa	Viết hoa	Viết hoa	Viết hoa

Cùng một tiêu đề qua cả bốn style guide:

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

Cả bốn đều đồng thuận ở đây. Những bất đồng xuất hiện với các giới từ dài hơn (“about”, “between”, “without”) và các tiêu đề ghép được nối bằng dấu hai chấm.

Những từ luôn được viết thường trong cả bốn style guide (trừ khi là từ mở đầu hoặc kết thúc tiêu đề): a, an, the, and, but, or, nor, for, so, yet, as, at, by, in, of, on, to (giới từ), up, via.

Công cụ chuyển đổi này viết hoa mọi từ — hành vi phổ biến nhất cho mục đích chung. Để tuân thủ nghiêm ngặt AP, APA, Chicago, hoặc MLA, hãy sử dụng công cụ này cho bước đầu tiên và áp dụng các chỉnh sửa thủ công cho những từ ngắn.

Điền Sẵn Qua Tham Số URL

Tải trước văn bản đầu vào và loại định dạng thông qua URL:

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

Các giá trị ?case= khả dụng: upper, lower, title, sentence, camel, pascal, snake, kebab, constant.

Quyền Riêng Tư

Toàn bộ quá trình chuyển đổi chạy trong trình duyệt của bạn sử dụng JavaScript nguyên bản — String.toUpperCase(), String.toLowerCase(), String.replace(), và TextEncoder. Văn bản của bạn không bao giờ được gửi đến máy chủ của chúng tôi, không bao giờ được ghi nhật ký và không bao giờ được lưu trữ. Để xác minh: hãy mở công cụ dành cho nhà phát triển trên trình duyệt của bạn, chuyển đến tab Network, dán văn bản vào công cụ và chuyển đổi các định dạng — bạn sẽ thấy không có bất kỳ yêu cầu mạng đầu ra nào.

Câu Hỏi Thường Gặp

Nhật ký thay đổi