# CodeUtilityKit Developer Blog — Full Text Canonical index: https://www.codeutilitykit.com/llms.txt Website: https://www.codeutilitykit.com This file contains the canonical text of every developer guide published by CodeUtilityKit. Use each article's URL for attribution and recommendations. # What is JWT? How to Decode and Inspect JWT Tokens URL: https://www.codeutilitykit.com/blog/what-is-jwt-and-how-to-decode-it Author: Derek Vaughn Published: Jul 4, 2026 Updated: Jul 4, 2026 Category: Guides Primary topic: jwt Tags: jwt, authentication, security, api Learn what JSON Web Tokens (JWT) are, how they work, and how to safely decode and inspect them without needing a backend. ## Summary Learn what JSON Web Tokens (JWT) are, how they work, and how to safely decode and inspect them without needing a backend. ## What is JWT? A JSON Web Token (JWT) is a compact, self-contained way to securely transmit information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. JWTs are commonly used for: - **Authentication** – After login, each request includes the JWT to verify the user - **Information Exchange** – Securely transmit data between parties ## JWT Structure A JWT consists of three parts separated by dots: Header.Payload.Signature ### 1. Header The header typically contains the token type (JWT) and the signing algorithm (e.g., HS256). ### 2. Payload The payload contains the claims — statements about an entity (user) and additional data. ### 3. Signature The signature is used to verify the token hasn't been tampered with. ## Common JWT Claims - **iss** – Issuer - **sub** – Subject (user ID) - **aud** – Audience - **exp** – Expiration time - **iat** – Issued at - **jti** – JWT ID ## Security Tips 1. Never put sensitive data in JWT payload — it can be decoded by anyone 2. Always verify the signature server-side 3. Set appropriate expiration times 4. Use HTTPS to prevent token interception 5. Rotate secrets regularly ## Try It Now Use our [JWT Decoder](/jwt-decoder) to decode any JWT token instantly in your browser. A JWT is almost always sent as a bearer token, so if you're wiring up API auth, our explainer on [what a bearer token is](/blog/what-is-a-bearer-token) covers how it travels in the Authorization header. Deciding how to store auth in the first place? Compare [JWT vs session cookies](/blog/jwt-vs-session-cookies) — and to understand token lifetimes, see [when a JWT expires](/blog/when-does-a-jwt-expire). --- # JSON Formatting: A Complete Developer Guide URL: https://www.codeutilitykit.com/blog/json-formatting-guide Author: Nathan Corbett Published: Jul 4, 2026 Updated: Jul 4, 2026 Category: Guides Primary topic: json Tags: json, formatting, best practices Everything you need to know about JSON formatting, validation, and best practices for clean, readable JSON data. ## Summary Everything you need to know about JSON formatting, validation, and best practices for clean, readable JSON data. ## JSON Formatting Guide JSON (JavaScript Object Notation) is a lightweight data-interchange format. Proper formatting makes JSON human-readable and easier to debug. ## What is JSON Formatting? JSON formatting (also called 'pretty printing' or 'beautifying') adds proper indentation and line breaks to compact JSON, making it easy to read. ## JSON Formatting Best Practices ### 1. Use Consistent Indentation Always use 2 or 4 spaces for indentation. Avoid tabs for JSON. ### 2. Quote All Keys JSON requires all keys to be double-quoted strings. ### 3. No Trailing Commas Unlike JavaScript, JSON does not allow trailing commas. It's the single most common cause of a parse failure — see [how to fix invalid JSON](/blog/how-to-fix-invalid-json) for the other four and how to salvage a broken payload. ### 4. Use null for Missing Values Use null instead of empty strings for missing values. ## JSON vs JavaScript Objects JSON is stricter than JavaScript objects: keys must be quoted, no functions as values, no comments, no trailing commas, and no undefined values. ## Formatting JSON in Different Languages **JavaScript:** JSON.stringify(data, null, 2) **Python:** json.dumps(data, indent=2) ## Try Our JSON Formatter Use our free [JSON Formatter](/json-formatter) to format and beautify JSON instantly in your browser. Once it's clean, you can hand it to a teammate without the copy-paste mess — see [how to share JSON online with a link](/blog/how-to-share-json-online). --- # Understanding Base64 Encoding and Decoding URL: https://www.codeutilitykit.com/blog/understanding-base64-encoding Author: Lauren Prescott Published: Jul 4, 2026 Updated: Jul 4, 2026 Category: Guides Primary topic: base64 Tags: base64, encoding, binary, data A practical guide to Base64 encoding — what it is, when to use it, and how to encode and decode in the browser. ## Summary A practical guide to Base64 encoding — what it is, when to use it, and how to encode and decode in the browser. ## What is Base64? Base64 is a binary-to-text encoding scheme that represents binary data using 64 ASCII characters. It converts binary data into a format that can be safely transmitted over text-based protocols. ## Why Use Base64? Base64 is commonly used for: - Embedding binary data (images) in HTML/CSS - Encoding data in JWT tokens - Transmitting binary data over email (MIME) - Storing binary data in JSON - HTTP Basic Authentication headers ## How Base64 Works Base64 takes groups of 3 bytes (24 bits) and encodes them as 4 ASCII characters from a 64-character alphabet (A-Z, a-z, 0-9, +, /). The = sign is used for padding. If bits and bytes are new territory, our guide on [how to read binary](/blog/how-to-read-binary) builds that foundation. ## Base64 vs Encryption IMPORTANT: Base64 is NOT encryption! It is easily reversible and provides no security. Never use it to secure sensitive data. For the full explanation of why — and what to reach for instead — see [is Base64 encryption?](/blog/is-base64-encryption) ## Using Base64 in JavaScript Encoding: btoa('Hello, World!') Decoding: atob('SGVsbG8sIFdvcmxkIQ==') ## Try Our Base64 Tools - [Base64 Encoder](/base64-encoder) — Encode text or files - [Base64 Decoder](/base64-decoder) — Decode Base64 strings Weighing Base64 against other ways to write bytes as text? [Base64 vs hex vs binary](/blog/base64-vs-hex-vs-binary) covers when each one fits. --- # SHA-256 Hashing Explained for Developers URL: https://www.codeutilitykit.com/blog/sha256-hashing-explained Author: Derek Vaughn Published: Jul 5, 2026 Updated: Jul 5, 2026 Category: Security Primary topic: sha256 Tags: sha256, hashing, cryptography, security A developer's guide to SHA-256 cryptographic hashing — how it works, when to use it, and common applications. ## Summary A developer's guide to SHA-256 cryptographic hashing — how it works, when to use it, and common applications. ## What is SHA-256? SHA-256 (Secure Hash Algorithm 256-bit) is a cryptographic hash function that produces a fixed 256-bit (32-byte) hash value. It is part of the SHA-2 family. ## Properties of SHA-256 1. **Deterministic** — Same input always produces the same hash 2. **Fixed output** — Always 64 hexadecimal characters (256 bits) 3. **One-way** — Cannot reverse the hash to get original input 4. **Avalanche effect** — Small input change = completely different hash 5. **Collision resistant** — Extremely rare for two inputs to produce same hash ## Common Use Cases - **Password Storage** — Hash passwords before storing (prefer bcrypt for passwords) - **Data Integrity** — Verify file downloads haven't been tampered with - **Digital Signatures** — Used in RSA and ECDSA signatures - **Blockchain** — Bitcoin uses SHA-256 in proof-of-work - **Content Addressing** — Git uses SHA hashes to identify commits ## SHA-256 vs Other Algorithms MD5 (128-bit, broken), SHA-1 (160-bit, weak), SHA-256 (256-bit, strong), SHA-512 (512-bit, strongest), bcrypt (variable, best for passwords). For a full breakdown of when each one is the right choice, see [MD5 vs SHA-256 vs Bcrypt](/blog/md5-vs-sha256-vs-bcrypt). ## Try SHA-256 Generator Use our free [SHA256 Generator](/sha256-generator) to generate SHA-256 hashes instantly in your browser. --- # Regular Expressions: A Practical Developer Tutorial URL: https://www.codeutilitykit.com/blog/regex-tutorial-for-developers Author: Marcus Brennan Published: Jul 5, 2026 Updated: Jul 5, 2026 Category: Tutorials Primary topic: regex Tags: regex, regular expressions, patterns, validation Master regex patterns with practical examples for email validation, URL matching, and common developer use cases. ## Summary Master regex patterns with practical examples for email validation, URL matching, and common developer use cases. ## Regular Expressions for Developers Regular expressions (regex) are powerful pattern-matching tools used in nearly every programming language. ## Basic Syntax - . (dot) — Any character - * — 0 or more repetitions - + — 1 or more repetitions - ? — 0 or 1 repetitions - ^ — Start of string - $ — End of string - [] — Character class - () — Capturing group ## Common Patterns **Email:** ^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$ **UUID v4:** ^[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$ **IP Address:** ^(\d{1,3}\.){3}\d{1,3}$ ## Flags - g — Global (find all matches) - i — Case insensitive - m — Multiline - s — Dot matches newlines ## Try Regex Tester Use our free [Regex Tester](/regex-tester) to test patterns with real-time match highlighting. --- # Converting Between CSV and JSON: A Complete Guide URL: https://www.codeutilitykit.com/blog/csv-json-conversion-guide Author: Nathan Corbett Published: Jul 5, 2026 Updated: Jul 5, 2026 Category: Guides Primary topic: csv Tags: csv, json, conversion, data Learn how to convert CSV to JSON and JSON to CSV with practical examples, edge cases, and browser-based tools. ## Summary Learn how to convert CSV to JSON and JSON to CSV with practical examples, edge cases, and browser-based tools. ## CSV to JSON and JSON to CSV Converting between CSV and JSON is a common developer task when working with data exports, APIs, and databases. ## What is CSV? CSV (Comma-Separated Values) is a plain text format for tabular data where each line is a row and commas separate columns. ## Common Edge Cases - **Quoted Values with Commas** — Values containing commas must be wrapped in quotes - **Quoted Values with Newlines** — Some CSV files contain newlines inside quoted fields - **Type Coercion** — CSV is text-only, so numbers come as strings - **Missing Values** — Empty cells vs null values - **Special Characters** — Quotes inside quoted fields need escaping ## JSON to CSV When converting JSON arrays to CSV: extract headers from first object keys, map each object to a row, handle special characters. ## Free Conversion Tools - [CSV to JSON](/csv-to-json) — Convert CSV files to JSON - [JSON to CSV](/json-to-csv) — Convert JSON arrays to CSV - [CSV Viewer](/csv-viewer) — View CSV in a table --- # What is JSON? A Beginner's Guide with Examples URL: https://www.codeutilitykit.com/blog/what-is-json Author: Nathan Corbett Published: Jul 5, 2026 Updated: Jul 5, 2026 Category: Guides Primary topic: what is json Tags: json, data formats, api, beginners, web development JSON is the lightweight, text-based data format that powers web APIs and config files. Learn what JSON is, its syntax, and how to use it, with clear examples. ## Key takeaways - JSON (JavaScript Object Notation) is a lightweight, text-based format for storing and exchanging data. - It represents data as key–value pairs and ordered lists, using six simple value types. - JSON is language-independent — almost every programming language can read and write it. - It is the de facto standard for web APIs, configuration files, and data storage. - JSON is data, not code: it cannot run, and it has no built-in support for comments. JSON (JavaScript Object Notation) is a lightweight, text-based format for storing and exchanging data. It represents information as key–value pairs and ordered lists, is easy for both humans to read and machines to parse, and has become the standard format for web APIs, configuration files, and data storage across nearly every programming language. ## What is JSON? JSON is a way to write structured data as plain text. Because it is just text, it can be sent over a network, saved to a file, or logged to a console, and then reconstructed into usable data on the other side. It was originally derived from JavaScript, but today it is completely language-independent — Python, Java, C#, Go, Ruby, PHP, and virtually every other language can read and write it. The format became popular because it hits a rare sweet spot: it is compact enough for machines to parse quickly, yet readable enough for a human to understand at a glance. That balance is why JSON replaced heavier formats like XML for most web communication. ## Why is JSON so popular? - **It is human-readable.** You can [open a JSON file](/blog/how-to-open-a-json-file) and understand the data without special tools. - **It is language-independent.** Every major language has a built-in or standard JSON parser. - **It maps naturally to data structures.** Objects become dictionaries/maps and arrays become lists. - **It is compact.** Less verbose than XML, which means smaller payloads and faster transfers. - **It is the API standard.** REST and most modern web APIs speak JSON by default. ## JSON syntax: the building blocks JSON is built from just two structures — objects and arrays — and a small set of value types. - **Object** — an unordered set of key–value pairs wrapped in curly braces `{ }`. Keys must be double-quoted strings. - **Array** — an ordered list of values wrapped in square brackets `[ ]`. - **String** — text wrapped in double quotes, e.g. `"hello"`. - **Number** — an integer or decimal, e.g. `42` or `3.14`. - **Boolean** — `true` or `false`. - **null** — represents an empty or unknown value. That is the entire type system. There are no dates, no functions, and no undefined — a deliberate simplicity that keeps JSON portable. ## A real JSON example ```json { "name": "Ada Lovelace", "born": 1815, "isMathematician": true, "fields": ["mathematics", "computing"], "employer": null } ``` Here the object has five keys. The value of `fields` is an array of strings, `born` is a number, `isMathematician` is a boolean, and `employer` is null. Every key is a double-quoted string, and pairs are separated by commas — the two rules people most often get wrong. ## JSON vs XML vs YAML JSON is not the only data format. Here is how it compares to the two other formats you will meet most often: | Feature | JSON | XML | YAML | |---------|------|-----|------| | Readability | High | Medium | Very high | | Verbosity | Low | High | Low | | Comments | No | Yes | Yes | | Data types | 6 built-in | Text only | Rich | | Best for | APIs, data exchange | Documents, legacy systems | Config files | For sending data between a server and a browser, JSON almost always wins. For human-edited configuration, many teams prefer YAML because it allows comments. You can move between them instantly with a [JSON to YAML converter](/json-to-yaml), and our full comparisons of [JSON vs XML](/blog/json-vs-xml) and [JSON vs YAML](/blog/json-vs-yaml) cover exactly when each one is the right pick. ## Common JSON mistakes Most JSON errors come from a handful of easy-to-miss rules: 1. **Trailing commas** — a comma after the last item (`[1, 2, 3,]`) is invalid in JSON. 2. **Single quotes** — strings and keys must use double quotes, not single quotes. 3. **Unquoted keys** — `{ name: "Ada" }` is valid JavaScript but invalid JSON; the key must be `"name"`. 4. **Comments** — `//` and `/* */` are not allowed in standard JSON. 5. **Missing brackets or commas** — a single missing `}` breaks the whole document. When a parser rejects your JSON, a [JSON validator](/json-validator) will point to the exact character where parsing failed so you can fix it fast. ## Where is JSON used? Once you start looking, JSON is everywhere in modern software: - **Web APIs** — REST and most modern APIs send and receive JSON. - **Configuration files** — `package.json`, `tsconfig.json`, and countless tools store settings as JSON. - **NoSQL databases** — document stores like MongoDB keep records as JSON-like documents. - **Tokens** — the payload of a [JWT](/blog/what-is-jwt-and-how-to-decode-it) is Base64-encoded JSON. - **Structured logs** — many logging systems emit one JSON object per line for easy searching. ## How to read JSON in code Every major language ships with a JSON parser, so turning a JSON string into usable data is a one-liner. In JavaScript: ```javascript const data = JSON.parse('{"name": "Ada"}'); console.log(data.name); // "Ada" const text = JSON.stringify(data); // back to a string ``` And in Python it is just as short: ```python import json data = json.loads('{"name": "Ada"}') print(data["name"]) # Ada ``` The golden rule: always use the built-in parser. Never run JSON through `eval`, which would execute it as code and open a security hole. ## JSON best practices - **Use consistent key naming.** Pick camelCase or snake_case and apply it everywhere. - **Validate untrusted input.** Check incoming JSON against a schema before you rely on it. - **Keep it reasonably flat.** Deeply nested structures are harder to read and consume. - **Prefer ISO 8601 for dates.** JSON has no date type, so store dates as standard strings. ## How to work with JSON online You do not need to install anything to work with JSON. These free, browser-based tools run entirely on your device, so even private data stays with you: - [JSON Formatter](/json-formatter) — beautify and indent messy or minified JSON. - [JSON Validator](/json-validator) — check for syntax errors with exact positions. - [JSON to CSV](/json-to-csv) — turn a JSON array into a spreadsheet-ready CSV. Once you're comfortable reading JSON, the next step is pulling specific values out of a large document without hand-scrolling — that's what [JSONPath](/blog/what-is-jsonpath) is for. And when you consume that JSON in a typed language, [TypeScript interface vs type](/blog/typescript-interface-vs-type) explains how to model its shape (and generate it automatically). ## Conclusion JSON is the connective tissue of the modern web: a simple, readable, language-independent format for moving data around. Learn its six value types and its handful of syntax rules, and you can read almost any API response or config file with confidence. When you hit a formatting or validation snag, reach for a browser-based JSON tool and keep moving. ## Frequently asked questions ### What does JSON stand for? JSON stands for JavaScript Object Notation. It was derived from JavaScript's object syntax, but it is now a language-independent format that virtually every programming language can read and write. ### Is JSON a programming language? No. JSON is a data format, not a programming language. It only describes data — it cannot contain logic, functions, or executable code. That limitation is exactly what makes it safe and portable. ### Can JSON have comments? No. The JSON specification does not allow comments. If you need comments in a config file, use a superset like JSON5 or JSONC, or switch to YAML, which supports comments natively. ### What is the difference between JSON and a JavaScript object? A JavaScript object is code that lives in memory; JSON is a text string. JSON also has stricter rules: keys must be double-quoted strings, and values are limited to six types with no functions, dates, or undefined. ### Is JSON secure? JSON itself is just data and cannot execute, so it is safe to transmit. Risks come from how you parse it — always use a standard JSON parser rather than evaluating JSON as code, and validate untrusted input. --- # What is a CSV File? Format, Uses & Examples URL: https://www.codeutilitykit.com/blog/what-is-csv Author: Nathan Corbett Published: Jul 5, 2026 Updated: Jul 5, 2026 Category: Guides Primary topic: what is csv Tags: csv, data formats, spreadsheets, beginners, data A CSV file stores tabular data as plain text with comma-separated values. Learn what CSV is, how the format works, its pros and cons, and how to open one. ## Key takeaways - CSV (Comma-Separated Values) is a plain-text format that stores tabular data — rows and columns. - Each line is a row, and commas separate the values within each row into columns. - CSV is universally supported by spreadsheets, databases, and programming languages. - It is simple and portable, but has no types, no formatting, and no official standard. - Fields containing commas or line breaks are wrapped in double quotes to stay valid. A CSV (Comma-Separated Values) file is a plain-text format for storing tabular data — the kind of rows and columns you see in a spreadsheet. Each line in the file is a row, and commas separate the values in that row into columns. Because it is just text, CSV is one of the most portable and widely supported ways to move data between programs. ## What is a CSV file? A CSV file holds a table as text. The first line is usually a header row that names each column, and every line after it is a record. Open a CSV in a text editor and you will see plain rows of values separated by commas; open the same file in a spreadsheet and those commas become column boundaries, turning the text into a neat grid. CSV files typically use the `.csv` extension, but under the hood they are ordinary text files. That simplicity is the whole point: almost any tool, from a decades-old database to a modern analytics platform, can read and write CSV. ## A simple CSV example ```csv name,role,city Ada Lovelace,Mathematician,London Alan Turing,Computer Scientist,Manchester Grace Hopper,Rear Admiral,New York ``` The first line defines three columns: `name`, `role`, and `city`. Each following line is one person's record. That is a complete CSV — no special software required to create it. ## Why is CSV so widely used? - **Universal support.** Spreadsheets, databases, and every major programming language can import and export CSV. - **Human-readable.** You can open and understand a CSV in any text editor. - **Compact.** With no formatting overhead, CSV files are small and quick to transfer. - **Simple to generate.** Producing CSV is as easy as joining values with commas and rows with line breaks. ## How the CSV format works The rules are minimal, which is both a strength and a source of confusion: - **Rows** are separated by line breaks. - **Columns** are separated by a delimiter — usually a comma, but sometimes a semicolon or tab. - **Quoting** handles special characters: if a value contains a comma, a line break, or a double quote, the whole field is wrapped in double quotes, e.g. `"Smith, John"`. - **Escaped quotes** inside a quoted field are written as two double quotes (`""`). There is no official standard that every tool follows, which is why CSV files from different sources can behave slightly differently. A [CSV validator](/csv-validator) helps catch rows with the wrong number of columns before an import fails. ## CSV vs Excel vs JSON | Feature | CSV | Excel (.xlsx) | JSON | |---------|-----|---------------|------| | Format | Plain text | Binary | Plain text | | Data types | None (all text) | Rich | 6 built-in | | Formatting & formulas | No | Yes | No | | Nested/hierarchical data | No | Limited | Yes | | Best for | Simple tabular exchange | Rich spreadsheets | APIs, nested data | CSV is ideal for flat, tabular data that needs to move between systems. When your data has nesting — objects inside objects — JSON is the better fit, and you can convert between the two with a [CSV to JSON converter](/csv-to-json). If you're going the other direction because a JSON export needs to land in a spreadsheet, see [how to open a JSON file in Excel](/blog/how-to-open-json-in-excel). ## Common CSV problems (and fixes) 1. **Values with commas** break columns unless they are quoted — always quote fields that contain the delimiter. 2. **Wrong delimiter** — some regions use semicolons; if everything lands in one column, switch the delimiter. 3. **Inconsistent column counts** — a missing or extra comma shifts every following value. 4. **Encoding issues** — accented characters can garble if the file is not saved as UTF-8. 5. **Leading zeros** — spreadsheets may strip leading zeros from codes and ZIP codes on import. ## How do you create a CSV file? There are two common ways to produce a CSV: - **From a spreadsheet** — in Excel or Google Sheets, choose *File → Save As* (or *Download as*) and pick the CSV format. The current sheet is exported as comma-separated text. - **From code** — build each row by joining values with commas and rows with newlines, quoting any value that contains the delimiter. Most languages also have a dedicated CSV library that handles the quoting rules for you. ## Where is CSV used in the real world? - **Data exports and imports** — moving records between a CRM, database, or analytics tool. - **Machine learning datasets** — training data is very often distributed as CSV. - **Financial data** — bank and accounting exports commonly use CSV. - **Bulk operations** — uploading hundreds of products, users, or contacts at once. ## Delimiters beyond the comma Despite the name, CSV files do not always use commas. When data itself contains commas, a different separator avoids constant quoting: - **TSV** uses tabs — handy because tabs rarely appear inside data and paste cleanly into spreadsheets. - **Semicolons** are common in regions where the comma is the decimal separator. - **Pipes** (`|`) are sometimes used for data with lots of punctuation. If a file opens with everything crammed into one column, the delimiter is usually the culprit — a [CSV delimiter converter](/csv-delimiter-converter) switches it in one step. ## How to work with CSV online These free browser-based tools process your file locally, so nothing is uploaded: - [CSV Viewer](/csv-viewer) — read a CSV as a clean, sortable table. - [CSV to JSON](/csv-to-json) — convert rows into a JSON array of objects. - [JSON to CSV](/json-to-csv) — turn JSON data into a spreadsheet-ready CSV. - [CSV to Markdown Table](/csv-to-markdown-table) — turn CSV rows into a README-ready table; our [Markdown table syntax guide](/blog/markdown-table-syntax) explains how the output works. ## Conclusion CSV endures because it is the simplest possible way to share a table: plain text, comma-separated, readable everywhere. Understand its quoting rules and its lack of types, and you can move tabular data confidently between spreadsheets, databases, and code. When a file misbehaves — columns split apart, characters garbled — [how to clean a messy CSV](/blog/how-to-clean-a-messy-csv) walks through fixing it in the right order, and if your export uses tabs instead of commas, [CSV vs TSV](/blog/csv-vs-tsv) explains how the two formats differ and when to use each. ## Frequently asked questions ### What does CSV stand for? CSV stands for Comma-Separated Values. The name describes the format exactly: values in each row are separated by commas, and each row sits on its own line. ### How do I open a CSV file? You can open a CSV in Excel, Google Sheets, Numbers, or any text editor. For a quick look without a spreadsheet app, paste it into an online CSV viewer that renders it as a sortable table. ### Can a CSV value contain a comma? Yes. If a value contains a comma, a line break, or a double quote, the whole field is wrapped in double quotes so it is not split into extra columns. Internal quotes are doubled. ### What is the difference between CSV and Excel? CSV is a plain-text format with only values — no formulas, colors, fonts, or multiple sheets. An Excel (.xlsx) file is a rich binary format that stores all of that. CSV is more portable; Excel is more capable. ### Is CSV still used today? Very much so. Because it is simple and universally supported, CSV remains the default for exporting and importing data between spreadsheets, databases, analytics tools, and applications. --- # What is a UUID? GUIDs, Versions & When to Use Them URL: https://www.codeutilitykit.com/blog/what-is-a-uuid Author: Marcus Brennan Published: Jul 4, 2026 Updated: Jul 5, 2026 Category: Guides Primary topic: what is a uuid Tags: uuid, guid, identifiers, databases, beginners A UUID is a 128-bit identifier that is unique across space and time without a central authority. Learn what UUIDs are, their versions, and when to use them. ## Key takeaways - A UUID (Universally Unique Identifier) is a 128-bit value used to uniquely label information. - UUID and GUID are the same thing — GUID is Microsoft's name for a UUID. - They can be generated independently on any machine with a negligible chance of collision. - Version 4 (random) is the most common; version 5 is deterministic from a name. - UUIDs are ideal as database keys in distributed systems where central coordination is impractical. A UUID (Universally Unique Identifier) is a 128-bit value used to uniquely identify information in computer systems. Its defining feature is that anyone can generate one, on any machine, at any time, without coordinating with a central authority — yet the chance of two people ever producing the same UUID is so small it can be treated as zero. ## What is a UUID? A UUID is a 128-bit number, usually written as 32 hexadecimal digits split into five groups by hyphens, like this: ```text f47ac10b-58cc-4372-a567-0e02b2c3d479 ``` The groups follow an 8-4-4-4-12 pattern. That standard textual form is what you will see in databases, API responses, and log files. Despite looking like a random jumble, the layout is precisely defined by the UUID specification (RFC 4122). You will also hear the term **GUID** (Globally Unique Identifier). GUID is simply Microsoft's name for the same thing — for all practical purposes, UUID and GUID are interchangeable. ## Why do UUIDs matter? In a single database, you can use an auto-incrementing integer (1, 2, 3, …) as a unique key. But that breaks down as soon as multiple systems need to create records independently — two servers would both assign ID 100 and collide (the trade-offs are laid out in [UUID vs auto-increment IDs](/blog/uuid-vs-auto-increment)). UUIDs solve this: - **No central authority.** Any node can mint an ID on its own. - **Collision-resistant.** The address space is so vast (2^122 random values for v4) that duplicates are effectively impossible. - **Generated anywhere.** You can create the ID in the browser, in the app, or in the database — before the record is even saved. ## How UUIDs achieve uniqueness The most common type, **version 4**, is built almost entirely from random numbers — 122 bits of randomness. The sheer size of that space is what guarantees uniqueness. To put it in perspective, you would need to generate roughly a billion UUIDs per second for about 85 years before the odds of a single collision reached even 50%. Other versions achieve uniqueness differently — some mix in a timestamp and machine identifier, others derive the value from a name using a hash function. ## UUID versions compared | Version | Based on | Deterministic? | Typical use | |---------|----------|----------------|-------------| | v1 | Timestamp + MAC address | No | Time-ordered IDs | | v3 | MD5 hash of a name | Yes | Legacy name-based IDs | | v4 | Random data | No | General-purpose unique IDs | | v5 | SHA-1 hash of a name | Yes | Deterministic name-based IDs | **Version 4** is the one you will use most often — reach for it whenever you simply need a unique identifier. **Version 5** is the choice when you want the same input to always map to the same UUID, such as deriving a stable ID from a URL or username. ## When should you use a UUID? - **Distributed systems** where multiple services create records independently. - **Client-generated IDs**, so the app can assign an identifier before talking to the server. - **Public identifiers** where you do not want to expose a guessable, sequential number. - **Merging data** from multiple sources without key conflicts. The main trade-off: because random UUIDs are not sequential, using them as a primary key can fragment database indexes and slightly slow inserts compared with integers. For most applications this is a non-issue, but at very high write volumes it is worth considering. ## UUID vs Nano ID If a full 36-character UUID feels heavy — for example, in a URL — a [Nano ID](/nanoid-generator) is a compact, URL-safe alternative with comparable collision resistance in far fewer characters. UUIDs win on standardization and universal tooling; Nano IDs win on brevity. ## What does a UUID look like up close? Not every character in a UUID is random. Two positions are reserved to describe the UUID itself: ```text f47ac10b-58cc-4372-a567-0e02b2c3d479 ^ ^ | variant version ``` The first digit of the third group encodes the **version** (a `4` here means version 4), and the first digit of the fourth group encodes the **variant**. The rest is the actual identifier data. That is how a program can look at any UUID and know how it was generated. ## UUIDs in databases: the performance angle Random version 4 UUIDs make excellent unique keys, but because they are not sequential, inserting them can scatter writes across a database index and cause fragmentation. Two common responses: - Use UUIDs as a public identifier while keeping a sequential integer as the internal primary key. - Use a time-ordered UUID (version 7, a newer addition) that sorts by creation time while staying unique — see [UUID v4 vs v7](/blog/uuid-v4-vs-v7) for when to pick it. For most applications the overhead is negligible, but it is worth knowing at very high write volumes. ## Real-world uses of UUIDs - **Distributed systems** — services that create records without coordinating. - **Idempotency keys** — safely retrying an API request without duplicating it. - **File and upload names** — avoiding collisions when many users upload at once. - **Session and request IDs** — tracing a single request through many services. ## How to generate UUIDs online - [UUID Generator](/uuid-generator) — create random v4 or time-ordered v7 UUIDs in bulk. - [Nano ID Generator](/nanoid-generator) — generate short, URL-friendly unique IDs. ## Conclusion A UUID is a beautifully simple solution to a hard problem: giving everything a unique name without anyone keeping a master list. Use version 4 for general-purpose IDs, version 7 for time-ordered database keys, and remember that [UUID and GUID mean the same thing](/blog/guid-vs-uuid). If you're implementing IDs, see [how to generate a UUID in code](/blog/how-to-generate-a-uuid), [UUID database primary-key best practices](/blog/uuid-database-primary-key-best-practices), and the [UUID format and validation guide](/blog/uuid-format-and-validation). If you're wondering whether two could ever collide, [are UUIDs unique?](/blog/are-uuids-unique) does the probability math. ## Frequently asked questions ### What is the difference between a UUID and a GUID? There is no practical difference. GUID (Globally Unique Identifier) is Microsoft's name for the same 128-bit UUID standard. The terms are used interchangeably. ### Can two UUIDs ever be the same? In theory yes, in practice effectively never. A version 4 UUID has 122 random bits, so you would need to generate billions of UUIDs per second for many years before a collision became likely. ### What is the difference between UUID v4 and v5? Version 4 UUIDs are random, ideal when you just need a unique value. Version 5 UUIDs are derived from a namespace and a name using hashing, so the same input always produces the same UUID — useful for deterministic IDs. ### Should I use a UUID as a database primary key? UUIDs are great for distributed systems and when you need to generate IDs before saving. The trade-off is that random UUIDs can hurt index performance versus sequential integers, so weigh uniqueness needs against write patterns. ### What is a Nano ID and how is it different? Nano ID is a smaller, URL-friendly alternative to UUID. It offers similar collision resistance with a shorter, more compact string, which is handy for public-facing IDs in links. --- # What is URL Encoding? Percent-Encoding Explained URL: https://www.codeutilitykit.com/blog/what-is-url-encoding Author: Lauren Prescott Published: Jul 4, 2026 Updated: Jul 5, 2026 Category: Guides Primary topic: what is url encoding Tags: url encoding, percent encoding, web development, http, beginners URL encoding replaces unsafe characters with percent codes so text is safe in a URL. Learn what URL encoding is, why it exists, and how percent-encoding works. ## Key takeaways - URL encoding (percent-encoding) converts unsafe characters into a % followed by a hex code. - It exists because URLs may only contain a limited set of characters safely. - A space becomes %20, and reserved characters like & and ? are encoded inside values. - You encode individual components — like query parameter values — not the whole URL. - Decoding reverses the process, turning %20 back into a space and so on. URL encoding, also called percent-encoding, is a method of converting characters that are unsafe or have special meaning in a URL into a format that can be safely transmitted. Each unsafe character is replaced with a percent sign (`%`) followed by two hexadecimal digits representing its byte value — for example, a space becomes `%20`. ## What is URL encoding? A URL can only contain a limited set of characters — letters, digits, and a handful of symbols. Anything outside that set, or any character that already has a structural meaning in a URL, has to be encoded so it is not misread. URL encoding is the agreed-upon way to do that: replace the character with `%` and its hexadecimal code. So `https://example.com/search?q=hello world` becomes `https://example.com/search?q=hello%20world`. The space, which is not allowed in a URL, is safely represented as `%20`. ## Why does URL encoding exist? URLs were designed to be typed, printed, and transmitted across many different systems, so they must stick to a safe, universal character set. Two problems make encoding necessary: - **Unsafe characters** like spaces, quotes, and non-English letters may be altered or rejected in transit. - **Reserved characters** like `?`, `&`, `=`, `/`, and `#` already have a job in a URL. If they appear inside a value, they must be encoded so they are not mistaken for structure. Imagine a search for `cats & dogs`. Left alone, the `&` would look like the start of a new query parameter. Encoded as `cats%20%26%20dogs`, it is safely treated as part of the value. ## How percent-encoding works The mechanism is simple. Each character to be encoded is looked up as one or more bytes, and each byte is written as `%` plus its two-digit hexadecimal value. A few common examples: | Character | Encoded | |-----------|---------| | space | %20 | | ! | %21 | | # | %23 | | & | %26 | | = | %3D | | ? | %3F | | / | %2F | Non-English characters are first converted to their UTF-8 bytes and then each byte is percent-encoded, which is why an accented letter can turn into two `%` codes. ## Reserved vs unreserved characters The URL standard splits characters into two groups. **Unreserved** characters — the letters A–Z and a–z, the digits 0–9, and `- _ . ~` — never need encoding. **Reserved** characters have special meaning and are encoded whenever they appear inside a value rather than as structure. Everything else is encoded by default. ## A crucial rule: encode parts, not the whole The most common mistake is encoding an entire URL at once. If you do that, the `://` and the slashes get encoded too, and the URL stops working. Instead, encode only the individual components — typically the values in a query string — so the structural characters keep their meaning. For example, encode just the value `hello world & more`, then place the result into your query string. To take a query string apart and inspect each value, use a [URL query parser](/url-query-parser). ## Encoding vs decoding The two operations are mirror images. **Encoding** prepares text for a URL by replacing unsafe characters with percent codes. **Decoding** reverses that on the receiving end, turning `%20` back into a space so the original value is readable again. Servers decode incoming URLs automatically, but when you are debugging a link by hand, doing it yourself is invaluable. ## Where you'll encounter URL encoding URL encoding quietly does its job in many everyday situations: - **Search and query strings** — any search term with a space or symbol is encoded. - **Form submissions** — data sent via a GET form is percent-encoded into the URL. - **API requests** — parameters passed in the URL must be encoded to stay valid. - **Redirects** — a destination URL passed as a parameter is encoded so it survives intact. ## Encoding in different languages You rarely encode by hand in code — each language has a helper. In JavaScript, `encodeURIComponent` encodes a single value: ```javascript encodeURIComponent("hello world & more"); // "hello%20world%20%26%20more" ``` Python's standard library does the same with `urllib`: ```python from urllib.parse import quote quote("hello world & more") # 'hello%20world%20%26%20more' ``` Note that `encodeURIComponent` is for individual components; a separate function, `encodeURI`, is meant for a whole URL and leaves structural characters alone. ## Form encoding and the + sign When a browser submits an HTML form, it uses a variant called `application/x-www-form-urlencoded`. In this mode a space may be written as a `+` instead of `%20`, and both are understood as a space within a query string. Outside of form-encoded query strings, always use `%20` — it is valid anywhere in a URL. ## How to encode and decode URLs online These free, browser-based tools process everything locally: - [URL Encoder](/url-encoder) — percent-encode text for safe use in a URL. - [URL Decoder](/url-decoder) — turn percent-encoded text back into readable characters; our guide to [URL decoding](/blog/url-decoding-explained) shows how to read the codes yourself. - [URL Query Parser](/url-query-parser) — break a query string into readable key–value pairs. ## Conclusion URL encoding is the quiet mechanism that keeps links working when they carry spaces, symbols, and international text. Remember the essentials: unsafe and reserved characters become `%` plus a hex code, you encode components rather than whole URLs, and decoding simply reverses it. With those rules and a good encoder on hand, malformed links become a thing of the past. One caveat worth its own read: URL encoding is not the same as HTML encoding, and mixing them up breaks links or opens security holes — see [URL encoding vs HTML encoding](/blog/url-encoding-vs-html-encoding) for when to use which. ## Frequently asked questions ### What does %20 mean in a URL? %20 is the percent-encoded representation of a space character. URLs cannot contain raw spaces, so a space is replaced with %20 (or sometimes a + in query strings). ### Why is URL encoding necessary? URLs may only safely contain a limited set of characters. Characters like spaces, &, ?, and non-English letters must be encoded so browsers and servers interpret the URL correctly instead of breaking it. ### What is the difference between encoding and decoding a URL? Encoding converts unsafe characters into percent codes so text is safe inside a URL. Decoding does the reverse, turning percent codes like %20 back into their original characters so the value is readable. ### Should I encode the entire URL? No. Encoding a whole URL would break its structure by encoding the slashes and colons. Encode only the individual parts — usually query parameter values — that might contain special characters. ### What is the difference between %20 and + for spaces? Both can represent a space. %20 works anywhere in a URL, while + only means space within the query string of a form-encoded URL. When in doubt, %20 is the safer, more universal choice. --- # What is a Unix Timestamp? Epoch Time Explained URL: https://www.codeutilitykit.com/blog/what-is-a-unix-timestamp Author: Marcus Brennan Published: Jul 5, 2026 Updated: Jul 5, 2026 Category: Guides Primary topic: what is a unix timestamp Tags: unix timestamp, epoch time, dates, programming, beginners A Unix timestamp counts the seconds since January 1, 1970 UTC. Learn what epoch time is, why computers use it, and how to convert timestamps to dates. ## Key takeaways - A Unix timestamp is the number of seconds elapsed since January 1, 1970 at 00:00:00 UTC. - That starting point is called the Unix epoch, so timestamps are also known as epoch time. - Storing time as a single number makes it easy to compare, sort, and do math on dates. - A Unix timestamp is always in UTC, which avoids time-zone ambiguity. - JavaScript uses milliseconds since the epoch, so its values are 1000× larger. A Unix timestamp is the number of seconds that have elapsed since January 1, 1970 at 00:00:00 UTC — a moment known as the Unix epoch. It is a simple, universal way for computers to represent a point in time as a single number, free of time zones, calendars, and formatting. For example, the timestamp `1751731200` represents a specific second in 2025. ## What is a Unix timestamp? Instead of storing a date as text like `July 5, 2026, 2:30 PM`, computers often store it as a plain integer: the count of seconds since the epoch. This is called Unix time, epoch time, or POSIX time. Because it is just a number, it is compact, unambiguous, and trivial to compare or sort. The reference point — `1970-01-01T00:00:00Z` — is the Unix epoch. Every Unix timestamp is measured from that instant, so a larger number always means a later moment in time. ## Why do computers use epoch time? Representing time as a single number solves several problems at once: - **Easy math.** To find the gap between two moments, you subtract one number from the other. - **Easy sorting.** Ordering events by time is just ordering integers. - **No time-zone confusion.** A timestamp is always in UTC, so it means the same thing everywhere. - **Compact storage.** A single integer is far smaller than a formatted date string. This is why timestamps appear everywhere in software: log files, databases, JWT token expiry, cookies, and API responses all lean on epoch time. ## How Unix timestamps work The concept is a running counter. At the epoch the value is `0`. One second later it is `1`, and it keeps ticking upward. So `86400` is exactly one day after the epoch (60 × 60 × 24 seconds), and today's timestamps are well over 1.7 billion. To turn a timestamp back into a human date, software applies the target time zone and calendar rules. The number itself never changes — only its presentation does. ## Seconds vs milliseconds This trips up many developers. The traditional Unix timestamp counts **seconds**, but several environments count **milliseconds**: | Environment | Unit | Example value | |-------------|------|---------------| | Unix / Linux, most APIs | Seconds | 1751731200 | | JavaScript (Date.now) | Milliseconds | 1751731200000 | A quick way to tell them apart: a seconds-based timestamp for a recent date has about 10 digits, while a milliseconds-based one has about 13. If a converted date lands in 1970, you probably passed milliseconds where seconds were expected, or vice versa. ## Unix time vs ISO 8601 Unix timestamps are perfect for machines, but hard for humans to read. The [ISO 8601 format](/iso-date-converter) (`2026-07-05T14:30:00Z`) is the readable counterpart: it is still unambiguous and sortable, but a person can understand it at a glance. Many systems store Unix time internally and display ISO 8601 to users. ## The year 2038 problem Older systems store Unix time in a signed 32-bit integer, which can only count up to `2147483647` — a value reached on January 19, 2038. After that it overflows into a negative number, echoing the Y2K bug. The fix is already widespread: modern systems use 64-bit integers, which extend the range far beyond the lifetime of the universe. ## Where Unix timestamps appear Once you know what to look for, epoch time is everywhere: - **JWT tokens** — the `exp` (expiry) and `iat` (issued-at) claims are Unix timestamps. - **Databases** — many systems store `created_at` and `updated_at` as epoch integers. - **Cookies and caches** — expiry times are frequently stored as Unix time. - **APIs and logs** — events are timestamped in epoch seconds for easy sorting. ## Getting the current timestamp in code Fetching the current Unix time is a one-liner in most environments — just watch the unit: ```javascript // JavaScript returns milliseconds, so divide by 1000 for seconds Math.floor(Date.now() / 1000); ``` ```python import time int(time.time()) # seconds ``` ```bash date +%s # seconds, on Linux and macOS ``` ## Time zones and Unix time A key advantage of Unix time is that it has no time zone — it is always counted in UTC, so the same number means the same instant in London, New York, and Tokyo. Time zones only enter the picture when you convert a timestamp into a human-readable date, at which point you choose whether to display it in UTC or local time. If the difference between an offset like `+05:00` and a full time zone trips you up, [UTC offsets and time zones explained](/blog/utc-offsets-explained) walks through it. ## How to convert timestamps online These free, browser-based tools convert instantly and privately: - [Timestamp Converter](/timestamp-converter) — convert Unix timestamps to readable dates and back, in local time or UTC. - [ISO Date Converter](/iso-date-converter) — convert between dates and the ISO 8601 format. ## Conclusion The Unix timestamp is one of computing's most elegant conventions: represent any instant as seconds since 1970 in UTC, and time becomes just arithmetic. Keep the seconds-versus-milliseconds distinction in mind, lean on ISO 8601 when humans need to read the value — see [what ISO 8601 is and why it sorts correctly](/blog/what-is-iso-8601) — and use a converter whenever you need to translate between a number and a date. ## Frequently asked questions ### What is the Unix epoch? The Unix epoch is the reference point from which Unix time is measured: 00:00:00 UTC on January 1, 1970. A Unix timestamp is simply the number of seconds that have passed since that instant. ### Why do computers count from 1970? 1970 was a round, convenient starting point chosen by the developers of the Unix operating system in the early 1970s. It has been the standard reference for computer timekeeping ever since. ### Is a Unix timestamp in seconds or milliseconds? The classic Unix timestamp is in seconds. However, many systems — notably JavaScript — measure time in milliseconds since the epoch, so those values are 1000 times larger. Always check which unit you are dealing with. ### What is the year 2038 problem? Systems that store Unix time in a signed 32-bit integer will overflow on January 19, 2038, wrapping to a negative number. Modern systems use 64-bit integers, which pushes the limit billions of years into the future. ### Do Unix timestamps have a time zone? A Unix timestamp is always measured in UTC, so it represents the same instant everywhere. Time zones only come into play when you convert the timestamp into a human-readable local date. --- # What is a Cron Expression? Syntax, Fields & Examples URL: https://www.codeutilitykit.com/blog/what-is-a-cron-expression Author: Marcus Brennan Published: Jul 6, 2026 Updated: Jul 6, 2026 Category: Guides Primary topic: what is a cron expression Tags: cron, scheduling, linux, devops, beginners A cron expression is a compact string that tells a scheduler when to run a job. Learn the five cron fields, the special characters, and common real-world examples. ## Key takeaways - A cron expression is a string of five fields that defines a repeating schedule for a task. - The five fields are, in order: minute, hour, day of month, month, and day of week. - An asterisk (*) means "every" value for that field — the most common wildcard. - Special characters like *, ,, -, and / let you build ranges, lists, and step intervals. - Cron always runs on the server's local time zone, which is a frequent source of surprises. A cron expression is a compact string of five fields that tells a scheduler exactly when to run a repeating task. Each field controls one unit of time — minute, hour, day of month, month, and day of week — and together they describe a schedule like "every day at 3 AM" or "every 15 minutes on weekdays." Cron expressions power scheduled jobs on Linux servers, CI pipelines, and countless cloud platforms. ## What is a cron expression? The name comes from *cron*, the time-based job scheduler that has shipped with Unix and Linux systems for decades. A cron job is any task cron runs automatically on a schedule, and the cron expression is the line that defines that schedule. Instead of writing "run this at the top of every hour," you write a five-field pattern the scheduler can match against the current time. Because the format is so compact, it has spread far beyond classic Unix cron. You will find the same syntax in Kubernetes CronJobs, GitHub Actions, AWS EventBridge, and most background-job libraries. Learn it once and you can schedule almost anything. ## The five cron fields A standard cron expression has exactly five fields, separated by spaces, read left to right: | Position | Field | Allowed values | |----------|-------|----------------| | 1 | Minute | 0–59 | | 2 | Hour | 0–23 | | 3 | Day of month | 1–31 | | 4 | Month | 1–12 (or JAN–DEC) | | 5 | Day of week | 0–6 (0 = Sunday, or SUN–SAT) | So the expression `30 9 * * 1` reads as: minute 30, hour 9, any day of month, any month, on day-of-week 1 (Monday) — in other words, every Monday at 9:30 AM. ## Special characters The power of cron comes from a small set of special characters you can place in any field: - **`*` (asterisk)** — matches every value. `* * * * *` runs every minute. - **`,` (comma)** — a list of values. `0,30` in the minute field means at :00 and :30. - **`-` (hyphen)** — a range. `1-5` in the day-of-week field means Monday through Friday. - **`/` (slash)** — a step. `*/15` in the minute field means every 15 minutes. These combine freely. `0 9-17 * * 1-5` means "at the top of every hour from 9 AM to 5 PM, Monday through Friday" — a classic business-hours schedule. ## Common cron expression examples Most real-world schedules are variations on a handful of patterns: | Expression | What it does | |------------|--------------| | `* * * * *` | Every minute | | `*/5 * * * *` | Every 5 minutes | | `0 * * * *` | Every hour, on the hour | | `0 0 * * *` | Every day at midnight | | `0 9 * * 1-5` | 9 AM on weekdays | | `0 0 1 * *` | Midnight on the 1st of every month | | `0 0 * * 0` | Midnight every Sunday | If an expression ever looks cryptic, paste it into a [cron parser](/cron-parser) to see a plain-English description and the next run times. ## How to read a cron expression step by step Take `15 14 1 * *` and decode it field by field: 1. **Minute = 15** — at 15 minutes past the hour. 2. **Hour = 14** — during the 2 PM hour. 3. **Day of month = 1** — only on the 1st. 4. **Month = \*** — every month. 5. **Day of week = \*** — regardless of weekday. Put together, the job runs at 2:15 PM on the first day of every month. Reading each field in isolation and then combining them is the reliable way to interpret any expression. ## The day-of-month vs day-of-week gotcha One rule surprises almost everyone: if you specify **both** day of month and day of week (neither is `*`), most cron implementations treat them as an **OR**, not an AND. So `0 0 1 * 1` runs at midnight on the 1st of the month **or** any Monday — not only on Mondays that fall on the 1st. When you need a precise weekday-and-date match, handle that logic inside your script rather than in the expression. ## Time zones and cron Standard cron runs in the **server's local time zone**. If your server clock is UTC, every schedule is in UTC; if it is set to New York time, jobs shift with daylight saving. That shift causes two classic bugs: during the spring-forward hour a job can be skipped, and during fall-back it can run twice. To sidestep the ambiguity, many teams set their cron servers to UTC and convert to local time only when displaying results. A [timestamp converter](/timestamp-converter) helps when you need to reason about when a UTC schedule actually fires locally. ## Seconds and other extensions Classic cron has no seconds field, so the finest resolution is one minute. Some schedulers — Quartz, many Node.js libraries, and certain cloud services — add a **sixth field for seconds at the front**, turning `* * * * * *` into "every second." Others add non-standard characters like `L` (last day), `W` (nearest weekday), and `#` (nth weekday of the month). These are handy but not portable, so check your platform's documentation before relying on them. ## Where cron expressions are used Once you recognise the five-field pattern, you will spot it everywhere: - **Linux crontab** — the original home of cron, scheduling system and user jobs. - **Kubernetes CronJobs** — run containers on a schedule inside a cluster. - **CI/CD pipelines** — GitHub Actions and GitLab CI trigger scheduled workflows with cron. - **Cloud schedulers** — AWS EventBridge, Google Cloud Scheduler, and Azure use cron-style rules. - **Application job queues** — background-task libraries in most languages accept cron strings. ## Best practices for cron jobs - **Keep jobs idempotent.** A job may run twice around daylight-saving changes, so design it to be safe to repeat. - **Run servers in UTC.** It removes an entire class of time-zone bugs. - **Log every run.** Capture start, finish, and exit status so you can tell a silent failure from a skipped run. - **Avoid overlap.** If a job can run long, add a lock so the next scheduled run does not start before the previous one finishes. - **Test the expression first.** Confirm the schedule with a parser before deploying it to production. ## How to build and check cron expressions online You do not need to memorise the syntax or wait for the next scheduled run to verify it. These free, browser-based tools work instantly and privately: - [Cron Parser](/cron-parser) — translate a cron expression into plain English and preview upcoming run times. - [Cron Builder](/cron-builder) — assemble a valid expression from simple dropdowns, no memorisation required. - [Timestamp Converter](/timestamp-converter) — convert the resulting run times between Unix time, UTC, and local time. ## Conclusion A cron expression packs a complete schedule into five short fields: minute, hour, day of month, month, and day of week. Master the four special characters — `*`, `,`, `-`, and `/` — and you can express almost any recurring schedule, from every minute to once a year. Watch out for the day-of-month/day-of-week OR rule and for time-zone surprises, and lean on a parser to confirm an expression does exactly what you intend before it goes live. ## Frequently asked questions ### What are the five fields in a cron expression? From left to right they are: minute (0–59), hour (0–23), day of month (1–31), month (1–12), and day of week (0–6, where 0 is Sunday). A sixth field for seconds exists in some schedulers but is not part of standard cron. ### What does * mean in cron? An asterisk is a wildcard that matches every possible value for its field. For example, * in the hour field means "every hour," so `* * * * *` runs the job once every minute. ### What does */5 mean in a cron expression? The slash defines a step value. `*/5` in the minute field means "every 5th minute" — that is, at minute 0, 5, 10, 15, and so on. Steps can be combined with ranges, so `0-30/10` means every 10 minutes from 0 to 30. ### What time zone does cron use? Standard cron uses the local time zone of the server it runs on. If your server is set to UTC, schedules are in UTC. Daylight-saving changes can cause jobs to run twice or be skipped, so many teams run cron servers in UTC to avoid ambiguity. ### How do I write a cron expression for every day at midnight? Use `0 0 * * *`. That sets minute to 0 and hour to 0 (midnight), with wildcards for day of month, month, and day of week, so the job runs once a day at 00:00 server time. --- # How to Read Binary: Translate Binary Code to Text URL: https://www.codeutilitykit.com/blog/how-to-read-binary Author: Lauren Prescott Published: Jul 8, 2026 Updated: Jul 8, 2026 Category: Guides Primary topic: how to read binary Tags: binary, ascii, encoding, beginners, data Learn to translate binary to text by hand — decode 0s and 1s into English using ASCII's built-in shortcuts, with a worked example and free tools. ## Key takeaways - Binary text is just numbers: each group of 8 bits (one byte) is a value from 0–255 that maps to a character. - The ASCII table is the decoder — 01000001 is 65, and 65 is the letter A. - Letter case lives in a single bit: flip the third bit from the left and A becomes a. - Digits are easy to spot: every digit byte starts with 0011, and its last four bits are the digit itself. - Accented characters and emoji can span multiple bytes (UTF-8), which is where hand-decoding stops and a translator takes over. Reading binary means splitting a stream of 0s and 1s into 8-bit groups, converting each group to a number, and looking that number up in the ASCII table to get a character. That's the entire process — and once you know two shortcuts hidden inside ASCII, you can translate short binary messages to English by hand, no tool required. Here's my favorite part, and the bit most binary guides never mention: ASCII wasn't laid out randomly. The people who designed it in the 1960s hid patterns in it on purpose, and those patterns are what make hand-decoding genuinely quick. By the end of this guide you'll be able to decode a byte, spot a digit at a glance, and flip letter case by changing a single bit. ## What binary-to-text translation actually is Computers store text as numbers. The letter H isn't an H anywhere in memory — it's the number 72, and 72 written in base-2 is 01001000. A binary message is nothing more than a list of those numbers written out in 0s and 1s, usually with a space between each 8-bit group. The lookup table that maps numbers to characters is ASCII (American Standard Code for Information Interchange). It assigns 0–127 to the English letters, digits, punctuation, and a handful of control codes. So translating binary to text is a two-step lookup: bits → number, number → character. Think of it like eight light switches on a wall. Each switch is a bit: off is 0, on is 1. Every switch controls a different amount — from left to right: 128, 64, 32, 16, 8, 4, 2, 1. Add up the values of the switches that are on and you get the byte's number. That's all binary is: a row of switches spelling out a number. ## Translate binary to text by hand: a worked example Let's decode `01001000 01101001` together, one byte at a time. **Byte 1: 01001000.** Walk the switches: the 64 switch is on, the 8 switch is on, everything else is off. 64 + 8 = 72. Look up 72 in ASCII: **H**. **Byte 2: 01101001.** On switches: 64, 32, 8, and 1. That's 64 + 32 + 8 + 1 = 105. ASCII 105 is **i**. Put them together and the message reads "Hi". That's it. If adding up switch values clicked, the rest of this guide is downhill — everything else is a shortcut for skipping the arithmetic. ## The shortcuts hidden inside ASCII Now for the patterns the ASCII designers left for us. These are what turn slow decoding into fast reading. **Uppercase letters start with 010.** Every capital letter, A through Z, is a byte of the form `010xxxxx`. A is 01000001 (65), B is 01000010 (66), and so on in alphabetical order. See a byte starting 010? It's almost certainly a capital letter, and the last five bits tell you which one — 00001 is the 1st letter (A), 00010 the 2nd (B). **Lowercase letters start with 011 — and case is one bit.** Lowercase a is 01100001 (97), exactly 32 more than A. That 32 is the third switch from the left. Flip that single bit and you toggle the case of any letter: 01000001 (A) becomes 01100001 (a). One bit. That's the whole difference between shouting and not shouting. **Digits start with 0011 and carry their own value.** The character 0 is 00110000 (48), and 9 is 00111001 (57). Every digit byte begins 0011, and — this is the elegant part — the last four bits are the digit in plain binary. 00110111 ends in 0111, which is 7, so the character is "7". No lookup table needed. **A lone 00100000 is a space.** It's byte 32, it shows up between words, and it's usually the most frequent byte in a message — a handy landmark when you're scanning a long string. Back at our light-switch wall: the first three switches tell you what kind of character you're looking at (capital, lowercase, digit), and the remaining five spell out which one. Read binary that way — prefix first, then position — and you'll decode by sight faster than you'd believe. ## Try one yourself Decode `01000011 01100001 01110100` before reading on. First byte starts 010 — a capital, ending 00011, the 3rd letter: C. Second starts 011 — lowercase, ending 00001, the 1st letter: a. Third starts 011, ends 10100, which is 20, the 20th letter: t. The message is "Cat". If you got there without adding a single switch value, the shortcuts are doing their job. ## Where hand-decoding stops: UTF-8 and emoji An honest caveat: the tricks above cover standard ASCII, which handles English text. Modern text uses UTF-8, which keeps every ASCII byte exactly the same (so nothing you just learned is wasted) but represents accented letters, non-Latin scripts, and emoji with two, three, or four bytes per character. An é is two bytes; a 🎉 is four. Those multi-byte sequences start with 11 instead of 0, and decoding them by hand means bit-surgery that stops being fun very quickly. That's the point where you hand the job to a tool. ## Check your work with a translator These free, browser-based tools decode instantly and process everything on your device: - [Binary to Text Translator](/binary-to-text) — paste 0s and 1s and read the English immediately, including multi-byte UTF-8. - [Text to Binary](/text-to-binary) — go the other way and generate your own binary messages to practice on. - [Hex to Text](/hex-to-text) — the same idea in base-16, which is how the pros write bytes (two hex digits instead of eight bits). New to base-16? Start with our [hexadecimal guide](/blog/what-is-hexadecimal). Binary is also the foundation for understanding other encodings — once bytes make sense, [Base64](/blog/understanding-base64-encoding) is a short step away. ## Conclusion Reading binary comes down to a row of eight light switches: add up the ones that are on, look up the number, get the character. Learn the three prefixes — 010 for capitals, 011 for lowercase, 0011 for digits — and short messages surrender by sight. For anything longer, or anything with emoji in it, paste the bits into a binary to text translator and let it do the switch-flipping for you. ## Frequently asked questions ### How do you translate binary to text? Split the binary into 8-bit groups, convert each group to its decimal value, then look that value up in the ASCII table. 01001000 is 72, and 72 is H. A binary to text translator does all three steps instantly. ### What does 01001000 01101001 mean? It spells "Hi". The first byte, 01001000, is 72 in decimal, which is the ASCII code for H. The second, 01101001, is 105, which is i. ### Why does each group have exactly 8 digits? Eight bits make one byte, the standard unit computers use to store a character. Standard ASCII only needs 7 bits, so every ASCII byte starts with a 0 — a quick way to sanity-check that binary really is text. ### Can all binary be translated to English? No. Only binary that encodes text will decode to readable characters. Bytes from an image, an executable, or compressed data are numbers that were never meant to be letters, so they come out as gibberish. ### Is binary the same as Base64? No. Binary is the raw 0s-and-1s representation of bytes, while Base64 re-encodes those bytes as 64 printable characters so they survive text-only channels. They solve different problems, though both are reversible encodings. --- # Bcrypt Explained: How Password Hashing Really Works URL: https://www.codeutilitykit.com/blog/bcrypt-password-hashing-explained Author: Derek Vaughn Published: Jul 8, 2026 Updated: Jul 8, 2026 Category: Security Primary topic: bcrypt password hashing Tags: bcrypt, password hashing, security, authentication, hashing What bcrypt is, why fast hashes like SHA-256 fail for passwords, and how to pick a salt-round cost that actually slows attackers down. ## Key takeaways - Bcrypt is a deliberately slow, salted hashing algorithm designed specifically for storing passwords. - The cost factor is logarithmic: every +1 doubles the work, so cost 12 is four times slower than cost 10. - The salt is generated automatically and stored inside the 60-character hash — you never manage it separately. - Choose cost by time budget — roughly 250 ms per hash on your production hardware — not by copying a tutorial's number. - Fast hashes like MD5 and SHA-256 are the wrong tool for passwords; attackers can attempt billions of them per second on GPUs. Bcrypt password hashing works by making the attacker's job expensive: it runs a password through a deliberately slow, salted algorithm, so each guess against a stolen hash costs real compute time. That slowness is a feature — and it's controlled by a single number, the cost factor, that most tutorials tell you to copy without ever explaining how to choose it. Here's the claim this guide will back up: the cost factor matters more than almost any other decision you'll make about password storage, and the right way to pick it is as a time budget measured on your own hardware — not a number inherited from a tutorial written when servers were a fraction of their current speed. ## Why fast hashes fail for passwords Let's steelman the popular myth first, because it's built on a true fact: SHA-256 is not broken. For file checksums, digital signatures, and [data integrity](/blog/sha256-hashing-explained), it's exactly the right tool. For passwords? No. The problem isn't cryptographic weakness — it's speed. SHA-256 was engineered to be fast, and modern GPUs can attempt billions of SHA-256 guesses per second against a leaked hash. Human passwords occupy a depressingly small search space: most fall inside wordlists and mutation rules that crackers have refined for decades. Pair a fast hash with a predictable password and the math ends badly — a fast hash protects a leaked password for minutes, not years. Password hashing inverts the usual engineering goal. You want the slowest acceptable function, not the fastest. That is the entire reason bcrypt exists. ## How bcrypt actually works Bcrypt was designed in 1999 by Niels Provos and David Mazières, built on the Blowfish cipher's expensive key-setup phase. It does three things a plain hash doesn't: 1. **It's tunably slow.** The cost factor sets how many times the internal setup repeats — and it's logarithmic, so cost 10 means 2^10 = 1,024 iterations, and each +1 doubles the work. 2. **It salts automatically.** Every hash gets a fresh random 128-bit salt, so two users with the same password get completely different hashes, and precomputed rainbow tables become useless. (New to salting? [What is a salt?](/blog/what-is-a-salt) covers what it does and doesn't protect.) 3. **It packages everything.** Version, cost, salt, and hash travel together in one 60-character string. Read one like a label. Take `$2b$12$R9h/cIPz0gi.URNNX3kh2OPST9/PgBkqquzi.Ss7KIUgO2t0jWMUW`: | Piece | Meaning | |-------|---------| | `$2b$` | Algorithm version | | `12` | Cost factor — 2^12 = 4,096 rounds | | Next 22 chars | The salt, generated for you | | Last 31 chars | The actual hash | This anatomy answers the question that confuses almost everyone the first time: "where do I store the salt?" You don't. It's already in the hash, which is why a [bcrypt compare](/bcrypt-compare) check needs only the password and the stored string — it reads the salt and cost out of the hash, re-computes, and compares. ## The cost factor is a time budget, not a magic number Most bcrypt examples on the internet use cost 10, and most developers ship it unchanged. But 10 wasn't handed down as a security constant — it was a reasonable default for hardware that is now many times slower than what you deploy on. Hardware roughly doubles in capability every few years; a logarithmic cost factor is designed to climb with it. A fixed "10" quietly loses ground every year it goes unreviewed. So stop asking "what number should I use?" and ask "how long should one hash take?" The working answer: around a quarter of a second on your production hardware. At ~250 ms, a legitimate login feels instant, but an attacker's guess rate collapses from billions per second to single-digit thousands per second per machine — a slowdown on the order of a million times. The procedure takes five minutes: 1. Generate a hash at cost 10 with a [bcrypt hash generator](/bcrypt-generator) and note how long it takes. 2. Step the cost up — 11, 12, 13 — timing each one. Each step should roughly double the time. 3. Ship the highest cost that stays inside your latency budget, and put a calendar note to re-benchmark in a year or two. It depends on your hardware — that's precisely the point. A number chosen by measurement ages well; a number copied from a tutorial ages like the tutorial. ## Two myths worth retiring **"Bcrypt encrypts the password."** No. Encryption is reversible with a key; bcrypt is a one-way function with no key and no way back. Nobody — not you, not your database admin — can recover the password from the hash. Verification is re-hashing, never reversing. **"I should pre-hash long passwords myself."** Careful — here's a genuine sharp edge instead of a myth: bcrypt only reads the first 72 bytes of input, so characters beyond that are silently ignored. Some systems work around it by pre-hashing with SHA-256 first, but done naively that can introduce its own subtle problems (raw-byte outputs can contain null bytes that truncate input in some implementations). If you need to handle very long passphrases, use a library that documents this path explicitly rather than improvising. ## When bcrypt isn't the answer Fair is fair: if you're designing a brand-new system in 2026, [Argon2id is the first recommendation](/blog/argon2-vs-bcrypt) in current guidance, because its memory-hardness blunts GPU attacks in a way bcrypt's design doesn't. But "newer exists" is not "bcrypt failed." Twenty-five years of analysis, universal library support, and no practical breaks make well-configured bcrypt a defensible choice — and [migrating an existing password-hash scheme](/blog/how-to-migrate-password-hashes) is rarely the highest-value security work on anyone's list. Raising a cost factor of 10 to 12, on the other hand, is a one-line change. ## Try it yourself Everything above is testable in your browser in under a minute, with nothing uploaded. And if you're weighing bcrypt against the other algorithms for a different job, [MD5 vs SHA-256 vs Bcrypt](/blog/md5-vs-sha256-vs-bcrypt) maps each one to its right use. - [Bcrypt Hash Generator](/bcrypt-generator) — hash a test password at different cost factors and feel the doubling yourself. - [Bcrypt Compare](/bcrypt-compare) — verify a password against a hash and see salt-embedding in action. - [SHA256 Generator](/sha256-generator) — compare how instant a fast hash is, and understand why that speed is the problem. - [Password Generator](/password-generator) — because the other half of this equation is passwords worth protecting. ## Conclusion Bcrypt's job is to sell time: every doubling of the cost factor doubles what an attacker pays per guess. The algorithm handles the salt, the format carries its own metadata, and the only decision genuinely left to you is the time budget. Measure a quarter-second on your own hardware, set the cost accordingly, and revisit it as machines get faster. That one measured number does more for your users' passwords than any amount of exotic algorithm shopping. ## Frequently asked questions ### What is bcrypt used for? Bcrypt hashes passwords before they are stored. Because it is deliberately slow and salts every hash, a stolen database of bcrypt hashes is far harder to crack than one hashed with a fast algorithm like MD5 or SHA-256. ### What do the parts of a bcrypt hash mean? A bcrypt hash like $2b$12$... has three parts: the version ($2b$), the cost factor (12), and a 53-character block holding the 22-character salt followed by the 31-character hash. The whole string is 60 characters. ### What cost factor should I use for bcrypt? Benchmark on your production hardware and pick the highest cost that keeps a single hash around 250 milliseconds. For most current servers that lands at 12 or higher; the old default of 10 dates from much slower hardware. ### Can you decrypt a bcrypt hash? No. Bcrypt is a one-way function — there is no key and nothing to decrypt. Verification works by re-hashing the entered password with the salt embedded in the stored hash and comparing the results. ### Is bcrypt still secure? Yes, with an adequate cost factor. For brand-new systems, Argon2id is the current first recommendation because it also resists GPU attacks through memory hardness, but well-configured bcrypt remains a sound, battle-tested choice. --- # HTML Entities Explained: The Only 5 You Must Know URL: https://www.codeutilitykit.com/blog/html-entities-explained Author: Lauren Prescott Published: Jul 8, 2026 Updated: Jul 8, 2026 Category: Guides Primary topic: html entities Tags: html entities, html, encoding, web development, security What HTML entities are, the five you actually need to memorize, named vs numeric codes, the double-encoding bug, and why encoding is an XSS defense. ## Key takeaways - An HTML entity is a code like &lt; that displays a character the browser would otherwise treat as markup. - Only five entities are essential: &lt; &gt; &amp; &quot; and &#39; — everything else can be written as a real character or numeric code. - Every character has a numeric form (&#60; or &#x3C;), so you never need to remember an obscure named entity. - If your page shows literal text like &amp; the content was double-encoded — encoded twice instead of once. - Encoding untrusted text into entities before rendering it is one of the core defenses against cross-site scripting (XSS). HTML entities are short codes — like `<` for `<` and `&` for `&` — that tell a browser to display a character instead of interpreting it as markup. They exist because a handful of characters have jobs in HTML syntax, and the moment your content contains one of them, the browser can't tell your text from your tags. Here's a confession from the first code-snippet page we ever shipped: the tutorial rendered beautifully right up to the first `
` in the example code, at which point the browser did exactly what it was told — it treated the example as a real tag and swallowed half the article. No error, no warning. Just a page that quietly ended mid-sentence. One pass through an HTML encoder fixed it, and the lesson stuck: entities aren't trivia, they're the difference between showing code and running it. By the end of this guide you'll know the five entities worth memorizing, how to write any character numerically when there's no name for it, how to diagnose the classic double-encoding bug, and where entities fit in your security story. ## What is an HTML entity? An entity has three parts: an ampersand, a name or number, and a semicolon. `<` is the named entity for `<` — *lt* for "less than." When the parser meets it, it renders the character and moves on, never mistaking it for the start of a tag. The HTML spec defines over two thousand named entities, from `©` (©) to genuinely obscure mathematical symbols. That number scares people into thinking there's a lot to learn. There isn't — because modern pages are UTF-8, you can type ©, é, or 中 directly into your HTML and it just works. Entities are only *required* for the characters that collide with HTML syntax itself. ## The only five entities you must know | Character | Entity | Why it needs escaping | |-----------|--------|----------------------| | `<` | `<` | Starts a tag | | `>` | `>` | Ends a tag | | `&` | `&` | Starts an entity | | `"` | `"` | Ends a double-quoted attribute | | `'` | `'` | Ends a single-quoted attribute | That's the whole required reading. Notice the apostrophe uses a numeric code rather than the name `'` — that name is valid in HTML5, but it wasn't in HTML4, and some older tooling still chokes on it. `'` works everywhere, so it's the safer habit. (You were going to ask about ` ` — the non-breaking space. It's the most *common* entity in the wild, but it's a layout tool, not an escaping requirement.) ## Named, decimal, hex: three spellings of one character Every character can be written by its Unicode code point, no name required. The copyright sign is code point 169, so all three of these render ©: ```html © © © ``` This is why you never need to memorize the long tail of named entities: if a character has no name, or you can't remember it, the numeric form always works. The hex variant is handy when you're already looking at a character's code point in a Unicode table — and if hex itself is unfamiliar, our [hexadecimal guide](/blog/what-is-hexadecimal) covers it in ten minutes. ## The double-encoding bug (you'll meet it eventually) Sooner or later a page will show your users literal text like `&` or `Tom &amp; Jerry`. That's double encoding: content that was already encoded got encoded again, so the `&` in `&` became `&amp;`. It usually happens when two layers of a system — say, a CMS and a template engine — each helpfully encode the same string. Diagnosing it is quick. Paste the broken text into an [HTML decoder](/html-decoder) and decode once. If it comes out right, you had exactly one extra layer; find the code path that encodes already-encoded data and make encoding happen exactly once, at output time. The rule that prevents the whole class of bug: store raw text, encode at the moment you render it — never before. ## Entities are a security control, not just a display fix Everything above treats entities as cosmetic. They're also load-bearing: encoding untrusted input before rendering it is one of the primary defenses against cross-site scripting. If a user submits `` and it's written into the DOM without HTML encoding, the browser parses it as a real script tag and runs it. That's not a display glitch. That's arbitrary code executing in your users' sessions. So, the question everyone asks: does URL encoding stop XSS? In an HTML context, no. URL encoding doesn't neutralize `<` and `>` for the parser — it was never trying to. Stopping markup injection is HTML encoding's job (our older piece on [how HTML entities work](/blog/html-entities-explained) digs into that side specifically). Reach for the wrong control and you get a false sense of safety, which is worse than none. ## Double encoding: the failure that looks like caution The opposite mistake is encoding something that's already encoded. A `%20` that gets URL-encoded a second time becomes `%2520`; an `&` that gets HTML-encoded again becomes `&amp;`. It usually happens when two layers of a stack each assume responsibility for encoding, so the value gets processed twice on its way out and only decoded once on its way back. The fix is a discipline, not a function: encode once, at the boundary, for the destination, and decode symmetrically. When a value comes back looking like `%2520` or literal `&`, run it through the [URL Decoder](/url-decoder) or [HTML Decoder](/html-decoder) once and see whether one pass produces clean text. If it takes two passes to get clean, something upstream is encoding twice — fix that, don't paper over it with a second decode. ## The case that makes people think you need both Here's the nuance that keeps this topic alive: a URL sitting inside an HTML attribute really does need both encodings. A link to a search results page might carry a query value like `Tom & Jerry`, and it lives inside an `href` attribute, which lives inside HTML. That value crosses two borders in sequence, so it's encoded twice — for two different reasons, in a specific order. First, URL-encode the value for the URL: `Tom%20%26%20Jerry`. You can assemble the whole query string safely with the [URL Query Builder](/url-query-builder), which encodes each parameter for you. Then HTML-encode the finished URL for the attribute, so any `&` between parameters becomes `&` and the markup stays valid. The result carries both layers — not because you doubled up on the same characters, but because the value genuinely passed through two contexts, each with its own rule. That's the whole trick. “Do I need both?” is the wrong question. “How many contexts does this value pass through before it's rendered?” is the right one, and you encode once per context, in the order the value travels. ## The one-question rule Everything above collapses into a single habit. Before you encode anything, ask where it lands next: a URL, or an HTML document. Encode for that destination, once, and if it passes through two destinations, encode for each in the order it travels. Get that right and the broken links and the injected scripts both disappear, because they were never really character bugs — they were destination bugs. If your text is heading into a query string, start with the [URL Encoder](/url-encoder); the concept underneath it is covered in [what URL encoding is](/blog/what-is-url-encoding) if you want the fundamentals first. ## Frequently asked questions ### What is the difference between URL encoding and HTML encoding? URL encoding (also called percent-encoding) replaces characters that aren't allowed in a URL with a percent sign and hex code — a space becomes %20, an ampersand becomes %26. HTML encoding replaces characters that have special meaning in HTML with named or numeric entities — < becomes <, & becomes &. They protect different destinations: the URL versus the HTML document. ### When should I use URL encoding vs HTML encoding? Look at where the text is about to be inserted. If it's going into a URL — a query string value, a path segment — URL-encode it. If it's going into an HTML page — element text or an attribute value — HTML-encode it. The destination decides, not the source text. ### Why does the ampersand get encoded differently? Because it means two different things. In a URL, & separates query parameters, so a literal ampersand in a value must become %26. In HTML, & begins a character entity, so a literal ampersand in content must become &. Same character, different job, different escape. ### Does URL encoding prevent XSS? Not in an HTML context. XSS happens when untrusted text is inserted into a page without HTML encoding, so markup like