42 Free Text Tools

Base64 Encoder/Decoder

<p>The Base64 Encoder/Decoder is a comprehensive tool for converting data to and from Base64 format. Base64 is one of the most widely used encoding schemes in computing, designed to represent binary data in an ASCII string format. This tool processes everything locally in your browser, ensuring your sensitive data never leaves your device.</p> <h3>What Is Base64 Encoding?</h3> <p>Base64 is a binary-to-text encoding scheme that represents binary data using 64 printable ASCII characters. The standard Base64 alphabet consists of uppercase letters (A-Z), lowercase letters (a-z), digits (0-9), plus sign (+), and forward slash (/), with equals sign (=) used for padding. This encoding was originally designed to safely transmit binary data over systems that only support text, such as email protocols.</p> <h3>How Base64 Encoding Works</h3> <p>The encoding process takes every three bytes (24 bits) of input data and splits them into four groups of 6 bits each. Each 6-bit group is then mapped to one of the 64 characters in the Base64 alphabet. If the input length isn't divisible by three, padding characters (=) are added to make the output length a multiple of four. This results in encoded data that is approximately 33% larger than the original, but completely safe for text-based transmission.</p> <h3>Common Use Cases for Base64</h3> <p>Base64 encoding is essential in modern web development and data transfer. Email attachments are encoded in Base64 to safely travel through SMTP servers. Data URIs use Base64 to embed images directly in HTML or CSS. API payloads often contain Base64-encoded binary data like images or files. Authentication headers, particularly Basic Auth, encode credentials in Base64. Configuration files and environment variables may contain Base64-encoded secrets.</p> <h3>URL-Safe Base64 Variant</h3> <p>Standard Base64 uses characters (+, /, =) that have special meanings in URLs. URL-safe Base64 replaces the plus sign with a hyphen (-) and the forward slash with an underscore (_). Some implementations also remove the padding equals signs. This variant is commonly used in JWT tokens, URL parameters, and filename encoding. Our tool supports both standard and URL-safe variants.</p> <h3>Base64 vs Other Encoding Schemes</h3> <p>While Base64 is widely used, alternatives exist for specific needs. Hex encoding is simpler but 100% larger than the original. Base32 is case-insensitive and avoids ambiguous characters but has 60% overhead. ASCII85 has only 25% overhead but uses more character types. Base64 strikes a balance between efficiency, simplicity, and compatibility, making it the most popular choice for general use.</p> <h3>Important Security Note</h3> <p>Base64 is an encoding scheme, not encryption. It provides no security whatsoever - anyone can decode Base64 data instantly. Never use Base64 alone to protect sensitive information like passwords, API keys, or personal data. If you need security, use proper encryption (like AES) and then optionally Base64-encode the encrypted output for safe transmission.</p> <h3>Browser-Based Privacy</h3> <p>This Base64 tool performs all encoding and decoding operations directly in your web browser using JavaScript. Your data is never transmitted to any server, stored in any database, or logged anywhere. This client-side processing ensures complete privacy, making it safe to encode sensitive content, API responses, or confidential files.</p>

Base32 Encoder/Decoder

<p>The Base32 Encoder/Decoder converts data to and from Base32 format, a binary-to-text encoding that uses 32 characters. Unlike Base64, Base32 is case-insensitive and avoids characters that could be confused with each other or have special meanings in URLs. This makes it ideal for scenarios where readability, human transcription, or case-insensitive systems are important.</p> <h3>What Is Base32 Encoding?</h3> <p>Base32 represents binary data using an alphabet of 32 characters: uppercase letters A-Z and digits 2-7. The encoding excludes digits 0, 1, 8, and 9 because they can be confused with letters O, I, B, and g respectively. This careful character selection makes Base32 much easier for humans to read, type, and transcribe accurately without errors.</p> <h3>How Base32 Encoding Works</h3> <p>Base32 encoding takes every 5 bytes (40 bits) of input and splits them into 8 groups of 5 bits each. Each 5-bit group is mapped to one of the 32 characters in the alphabet. The output is padded with equals signs to make the length a multiple of 8. This results in encoded data that is approximately 60% larger than the original - more overhead than Base64, but with better readability.</p> <h3>Base32 in Two-Factor Authentication</h3> <p>One of the most common uses of Base32 today is in Time-based One-Time Password (TOTP) authentication. When you set up two-factor authentication with an authenticator app, the secret key is typically encoded in Base32. This is because Base32's case-insensitivity makes it much easier for users to manually type the secret if they can't scan the QR code.</p> <h3>Comparison with Base64</h3> <p>While Base64 is more space-efficient (33% overhead vs 60%), Base32 offers distinct advantages. It's case-insensitive, making it work on systems that don't distinguish between uppercase and lowercase. It avoids characters like + and / that have special meanings in URLs and filenames. It excludes ambiguous characters, reducing human transcription errors. Choose Base32 when human readability matters more than efficiency.</p> <h3>Base32 Variants</h3> <p>Several Base32 variants exist for different use cases. RFC 4648 Base32 is the standard. Crockford's Base32 uses a different alphabet optimized for human use, including easy error correction. Extended Hex Base32 uses 0-9 and A-V, preserving sort order of encoded data. Our tool supports the standard RFC 4648 encoding.</p> <h3>Privacy and Security</h3> <p>Like all encoding tools on EncoderKit.cc, this Base32 encoder processes everything in your browser. No data is transmitted to servers, making it safe for encoding TOTP secrets, authentication keys, and other sensitive data. Remember that Base32 is encoding, not encryption - it doesn't provide security.</p>

Hex Encoder/Decoder

<p>The Hex Encoder/Decoder converts between text and hexadecimal (base 16) representation. Hexadecimal is fundamental to computing, providing a human-readable way to represent binary data. Each byte is displayed as two hex digits, making it easy to inspect raw data, debug protocols, and work with low-level computing concepts.</p> <h3>What Is Hexadecimal?</h3> <p>Hexadecimal is a base-16 number system using digits 0-9 and letters A-F (representing values 10-15). Since 16 is a power of 2 (2^4), each hex digit represents exactly 4 bits, and two hex digits represent one byte. This perfect alignment with binary makes hexadecimal the preferred format for representing binary data in computing.</p> <h3>Why Hexadecimal Is Used in Computing</h3> <p>Hexadecimal bridges the gap between binary (too long for humans) and decimal (doesn't align with bytes). A single byte (8 bits) requires 8 binary digits but only 2 hex digits. Memory addresses, color codes, MAC addresses, and byte-level data are all commonly expressed in hex. Programmers use the 0x prefix (like 0xFF) to indicate hexadecimal numbers.</p> <h3>Hexadecimal in Web Development</h3> <p>Web developers encounter hex regularly. CSS colors use hex codes (#FF5733). URL encoding represents special characters with %XX hex values. Debugging network traffic often shows hex dumps. Character codes and Unicode values are expressed in hex. Understanding hex is essential for modern web development.</p> <h3>Hex Dump Format</h3> <p>A hex dump shows data as hexadecimal bytes, often with ASCII representation alongside. This format is used by tools like hexdump, xxd, and hex editors. Our tool can output data with or without spaces between bytes, making it compatible with various hex dump formats and tools.</p> <h3>Using Hex for Binary Inspection</h3> <p>When debugging binary protocols, file formats, or encoded data, viewing hex representation reveals the exact bytes. You can spot file headers (magic bytes), identify encoding issues, analyze protocol packets, and understand data structures at the byte level. This tool makes such inspection easy and accessible.</p> <h3>Character Encoding Considerations</h3> <p>This tool encodes text as UTF-8 bytes before converting to hex. A simple ASCII character like 'A' becomes 41 (one byte). An emoji or non-ASCII character becomes multiple bytes. Understanding this encoding helps when working with international text or debugging character encoding issues.</p>

Binary Encoder/Decoder

<p>The Binary Encoder/Decoder converts between human-readable text and binary representation - the fundamental language of computers using only 0s and 1s. This tool is perfect for understanding how computers store text, learning about encoding, solving CTF challenges, or creating binary-themed visual effects.</p> <h3>What Is Binary?</h3> <p>Binary is the base-2 number system using only digits 0 and 1, called bits. All digital computing is built on binary because electronic circuits have two states: on (1) and off (0). Every piece of data in a computer - text, images, programs - is ultimately stored as sequences of these binary digits.</p> <h3>How Text Becomes Binary</h3> <p>When you type text, each character is assigned a numeric code (like ASCII or Unicode). That number is then converted to binary. For example, the letter 'A' has ASCII code 65, which is 01000001 in binary. A group of 8 bits is called a byte, and standard ASCII characters each require one byte.</p> <h3>Understanding Bits and Bytes</h3> <p>One bit can represent 2 values (0 or 1). Eight bits (one byte) can represent 256 values (0-255). Standard ASCII uses 7 bits for 128 characters, but is stored in 8-bit bytes. Extended ASCII and UTF-8 use 8 or more bits for additional characters. This tool uses UTF-8 encoding, so non-ASCII characters may require multiple bytes.</p> <h3>Educational Value</h3> <p>Converting text to binary helps you understand the fundamentals of computer science. You can see how characters are represented, understand why byte size matters, learn about encoding systems, and grasp why computers use powers of 2. This foundational knowledge benefits anyone working with technology.</p> <h3>Binary in Popular Culture and CTF Challenges</h3> <p>Binary appears frequently in hacker movies, escape rooms, and Capture The Flag (CTF) competitions. Messages hidden in binary add a technical mystique. Our tool makes it easy to encode secret messages in binary or decode binary strings found in puzzles and challenges.</p> <h3>Customization Options</h3> <p>The tool offers several formatting options. You can add spaces between bytes for readability, choose byte groupings (8-bit standard or custom), and toggle between different output formats. These options help match the binary format you're working with or prefer.</p>

ASCII85 Encoder/Decoder

<p>The ASCII85 Encoder/Decoder (also known as Base85) converts binary data using 85 printable ASCII characters. ASCII85 is more space-efficient than Base64, with only 25% size overhead compared to Base64's 33%. It's commonly used in PostScript, PDF files, and specialized applications where efficiency matters.</p> <h3>What Is ASCII85 Encoding?</h3> <p>ASCII85 (also called Base85) uses 85 printable ASCII characters to encode binary data. The name comes from using characters with ASCII codes 33 through 117 (85 characters). Four bytes of binary data are encoded as five ASCII85 characters, giving it better efficiency than Base64 (which encodes 3 bytes as 4 characters).</p> <h3>How ASCII85 Works</h3> <p>ASCII85 treats every 4 bytes of input as a 32-bit number. This number is then converted to base 85, producing 5 digits from 0 to 84. Each digit is mapped to a printable ASCII character by adding 33. Special handling exists for all-zero groups (encoded as 'z') and partial final groups. The result is wrapped in &lt;~ and ~&gt; delimiters in the standard format.</p> <h3>ASCII85 in Adobe Products</h3> <p>Adobe developed ASCII85 for use in PostScript and PDF files. When binary data (like images) needs to be embedded in these text-based formats, ASCII85 provides efficient encoding. Look at a PDF file's source and you'll often see ASCII85-encoded image data between &lt;~ and ~&gt; markers.</p> <h3>Comparison with Base64</h3> <p>ASCII85 has 25% overhead (4 bytes become 5 characters). Base64 has 33% overhead (3 bytes become 4 characters). For large files, this 8% difference is significant - a 100MB file becomes 125MB in ASCII85 vs 133MB in Base64. However, Base64 uses fewer special characters and is more widely supported.</p> <h3>Z85 and Other Variants</h3> <p>Several ASCII85 variants exist. Z85 (ZeroMQ Base-85) uses a different alphabet designed to be safe in more contexts. Btoa uses slightly different encoding rules. RFC 1924 specified an IPv6 encoding using Base85. Our tool supports the standard Adobe ASCII85 format with optional Z85 compatibility.</p> <h3>When to Use ASCII85</h3> <p>Choose ASCII85 when working with PostScript or PDF internals, when the 8% size savings over Base64 matters for large data, or when working with systems that specifically use ASCII85. For general web use, Base64 remains more practical due to broader support.</p>

Base58 Encoder/Decoder

<p>The Base58 Encoder/Decoder converts data using the Base58 alphabet, famously used in Bitcoin and cryptocurrency addresses. Base58 is similar to Base64 but removes easily confused characters (0, O, I, l) and problematic characters (+, /) to create addresses that are easy to read, transcribe, and use in various contexts.</p> <h3>What Is Base58 Encoding?</h3> <p>Base58 is a binary-to-text encoding scheme using 58 alphanumeric characters. It uses all digits (1-9, excluding 0), uppercase letters (A-Z, excluding I and O), and lowercase letters (a-z, excluding l). This careful character selection eliminates visual ambiguity and characters that cause problems in URLs or when copied.</p> <h3>Why Satoshi Nakamoto Chose Base58</h3> <p>The Bitcoin creator designed Base58 specifically for cryptocurrency addresses. The excluded characters were removed because: 0 and O look similar, I and l are hard to distinguish, and + and / would cause issues in URLs. This makes Bitcoin addresses easier to read, type manually, and share without errors.</p> <h3>Base58Check: Adding Checksums</h3> <p>Bitcoin addresses use Base58Check, which adds a checksum to detect transcription errors. Before Base58 encoding, a double SHA-256 hash is computed and the first 4 bytes are appended. This means typos in Bitcoin addresses will almost always be detected rather than sending to a wrong address.</p> <h3>Base58 in Cryptocurrency and Beyond</h3> <p>Beyond Bitcoin, Base58 is used in many cryptocurrency addresses (Bitcoin, Litecoin, Dogecoin), IPFS content identifiers (CIDs), Solana wallet addresses, and Flickr short URLs. Its human-friendly design makes it popular wherever users need to manually handle encoded identifiers.</p> <h3>Comparison with Base64</h3> <p>Base58 is less efficient than Base64 (more characters needed per byte) but more user-friendly. Base64 uses 64 characters including +, /, and =. Base58 uses 58 characters, all alphanumeric, with no ambiguous pairs. Choose Base58 when humans will interact with the encoded data.</p> <h3>Implementing Base58</h3> <p>Base58 encoding requires arbitrary-precision arithmetic because the encoding isn't aligned to byte boundaries like Base64. The input is treated as a big integer, divided repeatedly by 58, with remainders mapped to output characters. Leading zero bytes have special handling to produce leading '1' characters.</p>

URL Encoder/Decoder

<p>The URL Encoder/Decoder converts special characters into percent-encoded format for safe use in URLs, and decodes percent-encoded strings back to readable text. URL encoding is essential for web development, ensuring that special characters, spaces, and international text work correctly in web addresses and query parameters.</p> <h3>What Is URL Encoding?</h3> <p>URL encoding, also known as percent encoding, replaces unsafe ASCII characters with a "%" followed by two hexadecimal digits representing the character's ASCII code. For example, a space becomes %20, and an ampersand becomes %26. This allows characters with special meanings to be included in URLs without breaking their structure.</p> <h3>RFC 3986: The URL Standard</h3> <p>The official URL specification (RFC 3986) defines which characters are safe and which require encoding. Unreserved characters (A-Z, a-z, 0-9, -, _, ., ~) can appear as-is. Reserved characters (such as :, /, ?, #, @, &, =) have special meanings and must be encoded when used as data. All other characters should always be encoded.</p> <h3>Understanding encodeURI vs encodeURIComponent</h3> <p>JavaScript provides two functions with different behaviors. encodeURI() is for encoding complete URLs - it preserves characters needed for URL structure (://?#). encodeURIComponent() encodes everything except unreserved characters - use it for query parameter values. Most of the time, encodeURIComponent() is what you need.</p> <h3>Common URL Encoding Scenarios</h3> <p>Query parameters with spaces or special characters must be encoded. Form data submitted with application/x-www-form-urlencoded content type uses URL encoding. Redirect URLs passed as parameters need double encoding. File paths with special characters in URLs require encoding. International characters (like Chinese or Arabic text) must be encoded for URLs.</p> <h3>The Plus Sign Controversy</h3> <p>Historically, spaces in form submissions could be encoded as + instead of %20. While + is valid for application/x-www-form-urlencoded data, modern practice favors %20 for URLs. Our tool provides options for both behaviors. When in doubt, use %20 for maximum compatibility.</p> <h3>Debugging URL Issues</h3> <p>URL encoding problems are common web development bugs. Symptoms include broken links, missing parameters, or garbled text. This tool helps you decode problematic URLs to see their actual content, identify double-encoding issues, and create properly encoded URLs. Always test URLs with special characters thoroughly.</p>

HTML Entity Encoder/Decoder

<p>The HTML Entity Encoder/Decoder converts special characters to their HTML entity representations and back. HTML entities allow you to display characters that have special meanings in HTML (like < and &) or characters not easily typed on a keyboard. This encoding is essential for web security and proper HTML rendering.</p> <h3>What Are HTML Entities?</h3> <p>HTML entities are special codes that represent characters in HTML documents. They start with an ampersand (&) and end with a semicolon (;). For example, &lt; represents <, &amp; represents &, and &copy; represents ©. Entities ensure these characters display correctly instead of being interpreted as HTML code.</p> <h3>Named vs Numeric Entities</h3> <p>HTML entities come in two forms. Named entities use descriptive names like &amp;nbsp; (non-breaking space), &amp;copy; (copyright), or &amp;lt; (less than). Numeric entities use decimal (&amp;#169;) or hexadecimal (&amp;#xA9;) codes. Numeric entities can represent any Unicode character, while named entities are limited to a predefined set.</p> <h3>Preventing XSS Attacks</h3> <p>Cross-Site Scripting (XSS) attacks occur when malicious code is injected into web pages. Encoding user input as HTML entities prevents this - if someone submits &lt;script&gt;, it becomes &amp;lt;script&amp;gt; and displays as text instead of executing. Always encode user-generated content before inserting it into HTML.</p> <h3>Essential Characters to Encode</h3> <p>At minimum, these characters should always be encoded in HTML content: & becomes &amp;amp;, < becomes &amp;lt;, > becomes &amp;gt;, " becomes &amp;quot;, and ' becomes &amp;#39; or &amp;apos;. These characters can break HTML structure or enable injection attacks if left unencoded.</p> <h3>When to Use HTML Entities</h3> <p>Use entities when displaying user input in HTML, including special characters in HTML attributes, showing code examples on web pages, inserting characters not on your keyboard (like em-dashes or currency symbols), and ensuring correct display across different character encodings.</p> <h3>Common HTML Entities Reference</h3> <p>Useful entities include: &amp;nbsp; (non-breaking space), &amp;copy; (©), &amp;reg; (®), &amp;trade; (™), &amp;mdash; (—), &amp;ndash; (–), &amp;euro; (€), &amp;pound; (£), and &amp;hellip; (…). Our tool converts between these entities and their actual characters.</p>

Punycode Converter

<p>The Punycode Converter transforms internationalized domain names (IDN) between their Unicode form and ASCII-compatible Punycode representation. Punycode allows domain names to contain non-ASCII characters like Chinese, Arabic, or accented letters while remaining compatible with the ASCII-based domain name system (DNS).</p> <h3>What Is Punycode?</h3> <p>Punycode is an encoding system defined in RFC 3492 that converts Unicode strings to ASCII. It allows domain names to contain international characters by encoding them in a special format prefixed with "xn--". For example, "münchen.de" becomes "xn--mnchen-3ya.de" in Punycode.</p> <h3>How Punycode Works</h3> <p>Punycode uses a clever algorithm called Bootstring. It starts by separating ASCII characters, then encodes the positions and values of non-ASCII characters as a series of digits and letters. The result is always valid ASCII that can travel through the existing DNS infrastructure without modification.</p> <h3>The xn-- Prefix</h3> <p>All Punycode-encoded domain labels start with "xn--" (called the ACE prefix - ASCII Compatible Encoding). When your browser sees a domain with xn--, it knows to decode it and display the Unicode version. This is why you see "münchen.de" in your address bar even though the DNS uses "xn--mnchen-3ya.de".</p> <h3>Internationalized Domain Names (IDN)</h3> <p>IDN allows domain names in languages that don't use Latin characters. Countries can have domain names in their native scripts - Chinese domains in Chinese characters, Arabic domains in Arabic script, etc. This makes the internet more accessible to non-English speakers worldwide.</p> <h3>Punycode and Security: Homograph Attacks</h3> <p>Punycode enables a type of phishing called homograph attacks. Attackers register domains using characters that look similar to ASCII (like Cyrillic "а" instead of Latin "a"). This creates fake domains that appear identical to legitimate ones. Always verify URLs carefully, especially for sensitive sites.</p> <h3>Using the Converter</h3> <p>Enter a Unicode domain name to get its Punycode equivalent, or enter a Punycode string (with or without xn-- prefix) to see the Unicode characters. This is useful for debugging DNS issues, verifying domain registrations, and understanding how international domains work.</p>

Data URI Generator

<p>The Data URI Generator creates data URIs that embed file content directly in HTML, CSS, or JavaScript. Instead of linking to external files, data URIs include the actual file data inline, reducing HTTP requests and simplifying deployment. This tool is perfect for small images, icons, fonts, and other assets.</p> <h3>What Is a Data URI?</h3> <p>A Data URI (Uniform Resource Identifier) embeds data directly in a document using the format: data:[mediatype][;base64],data. For example, a small PNG image can become a data URI like "data:image/png;base64,iVBORw0KG..." that works anywhere a URL would work - in img src, CSS background-image, or JavaScript.</p> <h3>Data URI Structure</h3> <p>Every data URI has three parts: the "data:" scheme, an optional media type (like "image/png" or "text/plain"), an optional ";base64" indicator for Base64 encoding, and the actual data after a comma. Text can be included directly (with URL encoding) or Base64-encoded for binary data.</p> <h3>Benefits of Data URIs</h3> <p>Data URIs reduce HTTP requests, which can improve initial page load for small assets. They eliminate external file dependencies, making pages more self-contained. They work in email HTML where external images might be blocked. CSS sprites can be replaced with inline images.</p> <h3>Drawbacks and Considerations</h3> <p>Base64 encoding increases size by 33%, so large files become significantly bigger. Data URIs aren't cached separately by browsers - they're re-downloaded with the containing document. Browsers have size limits (varies by browser, typically 32KB+ is fine). Debug and readability suffer with large inline data.</p> <h3>When to Use Data URIs</h3> <p>Data URIs work best for small assets (under 10KB): icons, logos, simple graphics, and small fonts. They're excellent for CSS background images, single-page applications, email templates, and reducing requests on high-latency connections. Avoid them for large images or frequently-changed assets.</p> <h3>Browser Support</h3> <p>All modern browsers support data URIs. Internet Explorer had limitations (no data URIs in CSS before IE8, 32KB limit until IE9), but these legacy browsers are rarely relevant today. Test your specific use case if supporting older browsers.</p>

Query String Parser

<p>The Query String Parser converts between URL query strings and structured data. Parse complex query strings to see individual parameters, or build properly encoded query strings from key-value pairs. Essential for debugging API requests, constructing URLs, and understanding web application data flow.</p> <h3>What Is a Query String?</h3> <p>A query string is the part of a URL after the question mark (?). It contains key-value pairs separated by ampersands (&), like "?name=John&city=NYC". Query strings pass data to web pages and APIs, commonly used for search parameters, filters, pagination, and tracking codes.</p> <h3>Query String Syntax</h3> <p>Standard query string format uses = to separate keys from values and & to separate pairs. Keys and values are URL-encoded. Some frameworks support arrays (like key[]=1&key[]=2) or nested objects (like user[name]=John). Different frameworks parse these differently, which can cause compatibility issues.</p> <h3>Parsing Query Strings</h3> <p>When you paste a URL or query string into this tool, it extracts all parameters and displays them in a readable format. You can see each key-value pair decoded, identify duplicate keys, spot encoding issues, and understand exactly what data is being passed.</p> <h3>Building Query Strings</h3> <p>Enter key-value pairs (one per line as key=value) and the tool generates a properly encoded query string. Values are URL-encoded automatically, handling spaces, special characters, and Unicode text. The result can be copied and appended to any base URL.</p> <h3>Array and Nested Parameter Support</h3> <p>Different web frameworks handle arrays differently. PHP uses brackets (colors[]=red&colors[]=blue). Rails and some frameworks use numbered indices (colors[0]=red). This tool shows the raw parameter names, helping you debug framework-specific formats.</p> <h3>Debugging API Requests</h3> <p>When API calls fail or return unexpected results, query string issues are common culprits. This tool helps you verify parameters are encoded correctly, identify missing or malformed values, compare expected vs actual query strings, and understand complex parameter structures.</p>

MD5 Hash Generator

<p>The MD5 Hash Generator creates MD5 message digests from any text input. MD5 produces a 128-bit (32-character hexadecimal) hash that serves as a digital fingerprint of the input data. While MD5 is no longer recommended for security purposes, it remains widely used for checksums, file verification, and non-cryptographic applications.</p> <h3>What Is MD5?</h3> <p>MD5 (Message Digest Algorithm 5) is a cryptographic hash function designed in 1991 by Ronald Rivest. It takes an input of any length and produces a fixed 128-bit hash value, typically displayed as a 32-character hexadecimal string. Even a tiny change in input creates a completely different hash output.</p> <h3>How MD5 Hashing Works</h3> <p>MD5 processes input in 512-bit blocks, applying a series of bitwise operations, modular additions, and non-linear functions through four rounds. The algorithm maintains a 128-bit state that evolves through each block. After processing all blocks, the final state becomes the hash. This one-way process cannot be reversed to recover the original data.</p> <h3>MD5 Security Concerns</h3> <p>MD5 is cryptographically broken and unsuitable for security applications. Researchers demonstrated practical collision attacks in 2004-2005, meaning different inputs can be crafted to produce the same hash. Never use MD5 for password storage, digital signatures, or any security-critical purpose. Use SHA-256 or stronger algorithms instead.</p> <h3>Valid Uses for MD5 Today</h3> <p>Despite security weaknesses, MD5 remains useful for non-security applications. File integrity checks (detecting accidental corruption, not malicious tampering), generating short identifiers from data, database record fingerprinting, and cache key generation are all valid uses. MD5 is fast and produces compact hashes.</p> <h3>Verifying File Downloads</h3> <p>Software distributors often provide MD5 checksums to verify downloads weren't corrupted. Download the file, generate its MD5 hash, and compare with the published hash. Matching hashes mean the file arrived intact. Note: this only detects accidental corruption, not malicious modification.</p> <h3>MD5 Alternatives</h3> <p>For security purposes, use SHA-256 or SHA-3. For password hashing, use bcrypt, scrypt, or Argon2. For fast non-cryptographic hashing, consider xxHash or MurmurHash. For file integrity against tampering, use SHA-256 with digital signatures.</p>

SHA-1 Hash Generator

<p>The SHA-1 Hash Generator creates SHA-1 message digests from any text input. SHA-1 produces a 160-bit (40-character hexadecimal) hash that uniquely identifies input data. While deprecated for cryptographic use, SHA-1 remains in widespread use for legacy systems, Git commit hashes, and non-security applications.</p> <h3>What Is SHA-1?</h3> <p>SHA-1 (Secure Hash Algorithm 1) is a cryptographic hash function designed by the NSA and published in 1995. It takes any input and produces a 160-bit hash value, typically shown as a 40-character hexadecimal string. SHA-1 was the dominant hash algorithm for certificates, signatures, and integrity checking for nearly two decades.</p> <h3>SHA-1 Security Status</h3> <p>SHA-1 is considered cryptographically weak. Theoretical attacks emerged in 2005, and Google demonstrated a practical collision (SHAttered) in 2017. Major browsers and certificate authorities have deprecated SHA-1 for SSL/TLS. For security applications, migrate to SHA-256 or SHA-3.</p> <h3>SHA-1 in Git</h3> <p>Git uses SHA-1 to identify commits, trees, and blobs. Every Git commit has a SHA-1 hash based on its content and metadata. While concerns exist about collisions, Git's use case (accidental collision detection) differs from security applications. Git is transitioning to SHA-256 for new repositories.</p> <h3>The SHAttered Attack</h3> <p>In 2017, researchers from Google and CWI Amsterdam created two different PDF files with identical SHA-1 hashes. This SHAttered attack required enormous computational resources but proved SHA-1 collisions are practical. The attack accelerated SHA-1 deprecation across the industry.</p> <h3>When SHA-1 Is Still Acceptable</h3> <p>SHA-1 is acceptable for non-security purposes: checksums for accidental corruption detection, internal identifiers, and legacy system compatibility. It is NOT acceptable for digital signatures, certificate validation, password hashing, or any application where collision resistance matters.</p> <h3>Migration Path</h3> <p>Organizations should migrate from SHA-1 to SHA-256 or SHA-3. Most modern systems support SHA-256 natively. For gradual migration, you can dual-hash (compute both SHA-1 and SHA-256) during transition periods. New projects should use SHA-256 by default.</p>

SHA-256 Hash Generator

<p>The SHA-256 Hash Generator creates SHA-256 message digests from any text input. SHA-256 produces a 256-bit (64-character hexadecimal) hash and is the current standard for cryptographic hashing. It's used in Bitcoin, digital certificates, and security applications worldwide. This tool uses the Web Crypto API for efficient, secure hashing.</p> <h3>What Is SHA-256?</h3> <p>SHA-256 (Secure Hash Algorithm 256-bit) is part of the SHA-2 family designed by the NSA and published in 2001. It takes any input and produces a 256-bit hash value. SHA-256 is considered secure against all known attacks and is the workhorse of modern cryptography.</p> <h3>SHA-256 in Blockchain and Bitcoin</h3> <p>Bitcoin uses SHA-256 extensively. Mining involves finding inputs that produce hashes with specific properties (proof of work). Block headers are double-SHA-256 hashed. Transaction IDs are SHA-256 hashes. This widespread use has validated SHA-256's security under extreme scrutiny and computational attack.</p> <h3>SHA-256 for Digital Signatures</h3> <p>Most modern digital signature schemes use SHA-256 to hash documents before signing. TLS/SSL certificates use SHA-256 (certificates were migrated from SHA-1). Code signing, document signing, and email signatures typically rely on SHA-256 for integrity verification.</p> <h3>Security Strength</h3> <p>SHA-256 provides 128 bits of security against collision attacks and 256 bits against preimage attacks. No practical attacks or significant weaknesses have been found. Even with all computing power on Earth, brute-forcing SHA-256 would take longer than the age of the universe.</p> <h3>SHA-256 vs SHA-512</h3> <p>SHA-256 uses 32-bit operations, SHA-512 uses 64-bit. On 64-bit processors, SHA-512 can actually be faster. SHA-256 is standard for most applications. Use SHA-512 when you need longer hashes or when running on 64-bit systems where its performance advantage matters.</p> <h3>Using SHA-256 Correctly</h3> <p>SHA-256 is excellent for integrity verification, digital signatures, and proof-of-work. For password hashing, use bcrypt or Argon2 instead - they're deliberately slow. For HMAC authentication, combine SHA-256 with a secret key. Never use plain SHA-256 for password storage.</p>

SHA-512 Hash Generator

<p>The SHA-512 Hash Generator creates SHA-512 message digests from any text input. SHA-512 produces a 512-bit (128-character hexadecimal) hash, the largest in the SHA-2 family. It provides maximum security margins and can be faster than SHA-256 on 64-bit systems due to its native 64-bit operations.</p> <h3>What Is SHA-512?</h3> <p>SHA-512 (Secure Hash Algorithm 512-bit) is the largest member of the SHA-2 family. It processes data in 1024-bit blocks using 64-bit operations, producing a 512-bit output. The longer hash and larger internal state provide extra security margins compared to SHA-256.</p> <h3>SHA-512 vs SHA-256 Performance</h3> <p>Counterintuitively, SHA-512 can be faster than SHA-256 on 64-bit processors. SHA-512's native 64-bit operations execute efficiently on modern CPUs, while SHA-256's 32-bit operations may require more cycles. Benchmark on your specific platform to determine which performs better.</p> <h3>Truncated Variants: SHA-512/256 and SHA-512/224</h3> <p>SHA-512/256 computes a full SHA-512 hash but outputs only the first 256 bits. This combines SHA-512's 64-bit performance with SHA-256's output size. It also uses different initial values, preventing length extension attacks. Consider SHA-512/256 for the best of both worlds.</p> <h3>When to Choose SHA-512</h3> <p>Use SHA-512 when you need maximum security margins, when 64-bit performance matters, when longer hashes are beneficial (like unique identifiers), or when specifications require it. For general-purpose hashing, SHA-256 is typically sufficient and more widely supported.</p> <h3>Security Strength</h3> <p>SHA-512 provides 256 bits of security against collision attacks and 512 bits against preimage attacks. This exceeds even the most conservative security requirements. No known weaknesses exist in SHA-512.</p> <h3>Hash Length and Storage</h3> <p>SHA-512 hashes are 128 hexadecimal characters (or 64 bytes binary). This is twice the length of SHA-256. Consider storage and display requirements - 128 characters can be unwieldy in URLs or user interfaces where SHA-256's 64 characters fit better.</p>

HMAC Generator

<p>The HMAC Generator creates Hash-based Message Authentication Codes using a secret key combined with various hash algorithms. HMAC provides both data integrity and authentication, verifying that a message hasn't been altered and came from someone who knows the secret key. It's essential for API authentication, webhook signatures, and secure communications.</p> <h3>What Is HMAC?</h3> <p>HMAC (Hash-based Message Authentication Code) combines a cryptographic hash function with a secret key to produce a message authentication code. The formula is HMAC(K, m) = H((K' ⊕ opad) || H((K' ⊕ ipad) || m)). This construction provides security even if the underlying hash function has certain weaknesses.</p> <h3>HMAC vs Plain Hash</h3> <p>A plain hash (like SHA-256) only provides integrity - you can verify data hasn't changed. HMAC adds authentication - you can verify the data came from someone with the secret key. Without the key, an attacker cannot forge a valid HMAC even if they can see previous messages and their HMACs.</p> <h3>HMAC for API Authentication</h3> <p>Many APIs use HMAC for request authentication. The client computes HMAC of the request using their secret key, includes it in headers, and the server verifies it. AWS Signature Version 4, Stripe webhooks, and countless other APIs use HMAC-based authentication.</p> <h3>Choosing HMAC Algorithm</h3> <p>HMAC-SHA256 is the most common choice, offering good security and performance. HMAC-SHA512 provides more security margin if needed. HMAC-MD5 and HMAC-SHA1 should be avoided for new systems but may be required for legacy compatibility. The HMAC construction makes even weaker hashes more secure.</p> <h3>Key Management Best Practices</h3> <p>HMAC security depends entirely on key secrecy. Use cryptographically random keys of appropriate length (typically 32+ bytes). Never hardcode keys in source code. Rotate keys periodically. Store keys securely using environment variables, secret managers, or HSMs.</p> <h3>Webhook Signature Verification</h3> <p>Webhooks from payment processors, messaging services, and APIs use HMAC to prove authenticity. When you receive a webhook, compute HMAC of the body using your shared secret and compare with the provided signature. This prevents attackers from sending fake webhook events.</p>

Bcrypt Hash Generator

<p>The Bcrypt Hash Generator creates secure password hashes using the bcrypt algorithm. Bcrypt is specifically designed for password hashing with a built-in salt and adjustable work factor that makes brute force attacks increasingly expensive over time. It remains one of the most recommended algorithms for password storage.</p> <h3>What Is Bcrypt?</h3> <p>Bcrypt is a password hashing function designed by Niels Provos and David Mazières in 1999. Based on the Blowfish cipher, it incorporates a salt to prevent rainbow table attacks and a cost factor that controls computational expense. The algorithm is deliberately slow, making brute force attacks impractical.</p> <h3>Why Bcrypt for Passwords?</h3> <p>Unlike general-purpose hashes like SHA-256, bcrypt is designed specifically for passwords. It's slow by design (adjustable via cost factor), includes automatic salt generation, and uses memory-hard operations that resist GPU acceleration. These properties make bcrypt excellent at resisting password cracking.</p> <h3>Understanding the Cost Factor</h3> <p>The cost factor (also called work factor or rounds) determines bcrypt's computational cost. Each increment doubles the time required. A cost of 10 (2^10 = 1024 rounds) takes about 100ms on modern hardware. Cost 12 takes about 400ms. Choose a cost that takes 250ms-1s for your server - this barely affects legitimate logins but massively slows attacks.</p> <h3>Bcrypt Output Format</h3> <p>Bcrypt hashes follow the format: $2b$cost$salt(22)hash(31). For example: $2b$10$N9qo8uLOickgx2ZMRZoMye. The $2b$ identifies the algorithm version, 10 is the cost factor, followed by 22 characters of salt and 31 characters of hash. Everything needed for verification is in one string.</p> <h3>Salt Handling</h3> <p>Bcrypt automatically generates and embeds a random salt in each hash. You never need to manage salts separately. When verifying passwords, bcrypt extracts the salt from the stored hash. This design prevents rainbow table attacks and ensures identical passwords produce different hashes.</p> <h3>Bcrypt Limitations</h3> <p>Bcrypt truncates passwords at 72 bytes - longer passwords are effectively shortened. For very long passwords, consider pre-hashing with SHA-256. Some implementations have a maximum cost factor. The algorithm is well-studied but not the newest; Argon2 is a modern alternative.</p>

Hash Identifier

<p>The Hash Identifier analyzes hash strings to determine their likely algorithm based on length, character set, and format patterns. Paste any hash and instantly see potential matches including MD5, SHA-1, SHA-256, bcrypt, and many more. Essential for security research, CTF challenges, and debugging unknown hash formats.</p> <h3>How Hash Identification Works</h3> <p>Different hash algorithms produce outputs with distinct characteristics. MD5 always produces 32 hex characters, SHA-256 produces 64, bcrypt starts with $2b$ and is 60 characters. By analyzing these patterns, we can determine likely hash types. Some lengths are ambiguous (MD5 and NTLM both produce 32 hex characters), so multiple possibilities may be shown.</p> <h3>Common Hash Types and Lengths</h3> <p>MD5: 32 hex characters (128 bits). SHA-1: 40 hex characters (160 bits). SHA-256: 64 hex characters (256 bits). SHA-512: 128 hex characters (512 bits). Bcrypt: 60 characters starting with $2b$. Argon2: Starts with $argon2. These patterns help narrow down identification.</p> <h3>Identifying Password Hashes</h3> <p>Modern password hashes like bcrypt, Argon2, and scrypt have distinctive prefixes. Bcrypt uses $2a$, $2b$, or $2y$. Argon2 uses $argon2i$, $argon2d$, or $argon2id$. These self-identifying formats include the algorithm, parameters, salt, and hash in one string.</p> <h3>Hash Format Prefixes</h3> <p>Many hash formats use standard prefixes: $1$ for MD5-crypt, $5$ for SHA-256-crypt, $6$ for SHA-512-crypt, {SSHA} for salted SHA in LDAP. This tool recognizes these prefixes and identifies the specific variant being used.</p> <h3>CTF and Security Research</h3> <p>In Capture The Flag competitions and penetration testing, you often encounter unknown hashes. Quick identification helps determine the appropriate cracking approach. Different tools and wordlists are optimal for different hash types.</p> <h3>Limitations</h3> <p>Hash identification can suggest likely algorithms but cannot guarantee correctness. Many algorithms produce the same length output (MD5 vs NTLM, CRC32 vs Adler32). Without context about where the hash came from, multiple interpretations may be valid. Always verify with the source system when possible.</p>

JWT Decoder

<p>The JWT Decoder parses JSON Web Tokens to reveal their header and payload contents. JWTs are widely used for authentication and authorization in web applications. This tool lets you inspect token claims, verify expiration times, and debug authentication issues without needing to write code or use developer tools.</p> <h3>What Is a JWT?</h3> <p>A JSON Web Token (JWT) is a compact, URL-safe means of representing claims between two parties. It consists of three Base64-encoded parts separated by dots: header.payload.signature. The header specifies the algorithm, the payload contains claims (user data, expiration, etc.), and the signature verifies the token hasn't been tampered with.</p> <h3>JWT Structure</h3> <p>The header typically contains the token type ("typ": "JWT") and signing algorithm ("alg": "HS256" or "RS256"). The payload contains claims - registered claims like exp (expiration), iat (issued at), sub (subject), plus custom claims like user roles or permissions. The signature is created using the header, payload, and a secret key.</p> <h3>Common JWT Claims</h3> <p>Standard registered claims include: iss (issuer), sub (subject), aud (audience), exp (expiration time), nbf (not before), iat (issued at), and jti (JWT ID). Applications add custom claims for user information, roles, permissions, and session data. This decoder displays all claims clearly.</p> <h3>JWT Security Considerations</h3> <p>JWTs are signed, not encrypted - anyone can decode and read the payload. Never put sensitive data in JWTs. Verify signatures server-side before trusting claims. Check expiration times. Be aware of algorithm confusion attacks where attackers change HS256 to "none". Always validate the "alg" header.</p> <h3>Debugging Authentication Issues</h3> <p>When authentication fails, decoding the JWT helps identify problems: expired tokens (check exp claim), wrong issuer/audience, missing required claims, or malformed structure. This tool shows exact timestamps converted to readable dates, making expiration debugging straightforward.</p> <h3>JWTs in Modern Applications</h3> <p>JWTs power authentication in SPAs, mobile apps, and APIs. OAuth 2.0 access tokens and OpenID Connect ID tokens are often JWTs. Understanding their structure helps debug SSO, API authorization, and identity management systems.</p>

JWT Encoder

<p>The JWT Encoder creates JSON Web Tokens from your specified header and payload with signing using your secret key. Build custom tokens for testing, development, and learning. Specify any claims, choose signing algorithms, and generate properly formatted JWTs that work with standard JWT libraries.</p> <h3>Creating Custom JWTs</h3> <p>Enter your desired payload as JSON, including any claims needed: subject (sub), expiration (exp), issuer (iss), or custom claims. Choose a signing algorithm and enter your secret key. The tool generates a properly signed JWT that any standard JWT library can verify.</p> <h3>Supported Algorithms</h3> <p>This tool supports HMAC algorithms (HS256, HS384, HS512) using symmetric keys. These are suitable for testing and development. For production with asymmetric algorithms (RS256, RS512), use proper key management systems rather than online tools.</p> <h3>Setting Expiration Times</h3> <p>The exp claim uses Unix timestamps (seconds since January 1, 1970). For a token expiring in 1 hour, add 3600 to the current timestamp. Many applications use short-lived tokens (15 minutes to 1 hour) with refresh token patterns for security.</p> <h3>Standard Claims Reference</h3> <p>iss (issuer) - who created the token. sub (subject) - the user or entity. aud (audience) - intended recipient. exp (expiration) - when token expires. nbf (not before) - when token becomes valid. iat (issued at) - creation timestamp. jti (JWT ID) - unique identifier.</p> <h3>Testing and Development Use</h3> <p>Create test tokens with specific claims to debug your authentication logic. Test expiration handling by creating already-expired tokens. Verify your backend correctly rejects tampered or invalid tokens. This tool is excellent for development and testing scenarios.</p> <h3>Security Warning</h3> <p>Never use online tools to create production tokens with real secrets. This tool is for testing, learning, and development only. Production JWT signing should happen in secure backend environments with proper key management.</p>

OAuth Token Decoder

<p>The OAuth Token Decoder inspects OAuth 2.0 access tokens and OpenID Connect ID tokens. Many OAuth implementations use JWTs for tokens, making their claims readable. This tool helps you understand token contents, verify scopes, and debug OAuth authorization issues.</p> <h3>OAuth 2.0 Token Types</h3> <p>OAuth 2.0 defines several token types. Access tokens authorize API requests. Refresh tokens obtain new access tokens. ID tokens (from OpenID Connect) contain user identity information. This tool decodes JWT-formatted tokens to reveal their contents.</p> <h3>Understanding Access Token Claims</h3> <p>OAuth access tokens may contain: scope (permissions granted), client_id (the application), sub (the user), exp (expiration), iat (issued at), and iss (authorization server). Provider-specific claims vary - Google, Azure, Auth0 each add different custom claims.</p> <h3>OpenID Connect ID Tokens</h3> <p>ID tokens from OIDC contain identity claims: sub (unique user identifier), name, email, picture, and more depending on requested scopes. They're always JWTs and must be validated before trusting claims. This tool shows you what claims are present.</p> <h3>Opaque vs Self-Contained Tokens</h3> <p>Not all OAuth tokens are JWTs. Some providers issue opaque tokens (random strings) that must be validated via introspection endpoint. If a token doesn't decode as JWT, it's likely opaque and can only be validated server-side with the provider.</p> <h3>Debugging Authorization Issues</h3> <p>When API calls return 401/403 errors, check the token: Is it expired? Does it have required scopes? Is the audience correct? This tool reveals these claims instantly, speeding up OAuth debugging significantly.</p> <h3>Token Security Reminder</h3> <p>Access tokens are credentials. Treat them like passwords. Don't log them, share them, or store them insecurely. Use short expiration times. This tool processes tokens locally - never paste production tokens into server-based decoders.</p>

API Key Generator

<p>The API Key Generator creates cryptographically secure random keys suitable for API authentication, access tokens, and secret keys. Generate keys in various formats with customizable length, prefixes, and character sets. Uses the Web Crypto API for true cryptographic randomness.</p> <h3>Cryptographic Randomness</h3> <p>This tool uses the browser's Web Crypto API (crypto.getRandomValues) for generating keys. This provides cryptographically secure pseudo-random numbers suitable for security-sensitive applications. Unlike Math.random(), these values are unpredictable and safe for authentication tokens.</p> <h3>API Key Formats</h3> <p>Choose from multiple formats: alphanumeric (A-Z, a-z, 0-9), hexadecimal (0-9, a-f), URL-safe Base64, or custom character sets. Many APIs use prefixes like "sk_live_" or "api_" to identify key types. Our tool supports custom prefixes for organizational clarity.</p> <h3>Recommended Key Lengths</h3> <p>For general API keys, 32-64 characters provide excellent security. Shorter keys (16 characters) work for low-security use cases. Encryption keys should be exactly the required bit length (32 bytes for AES-256). Longer isn't always better - match your security requirements.</p> <h3>Key Prefixes and Organization</h3> <p>Prefixes help identify key types and environments: "pk_" for public keys, "sk_" for secret keys, "_test_" or "_live_" for environments. Stripe popularized this pattern. Prefixes make keys easier to manage and help prevent accidentally using test keys in production.</p> <h3>Secure Key Storage</h3> <p>Generated keys are only as secure as their storage. Use environment variables or secret management services (AWS Secrets Manager, HashiCorp Vault). Never commit keys to version control. Rotate keys periodically. Hash keys for storage if you only need to verify them.</p> <h3>Multiple Key Generation</h3> <p>Generate multiple keys at once for batch operations. Useful when provisioning many API clients, creating key pairs, or generating backup keys. Each key is independently random - no patterns or relationships between generated keys.</p>

Unicode Escape/Unescape

<p>The Unicode Escape tool converts between readable characters and Unicode escape sequences. Escape sequences like \u0041 (letter A) or \u4E2D (Chinese character) represent characters by their Unicode code points. This format is commonly used in JavaScript, JSON, Java, and many programming languages.</p> <h3>What Are Unicode Escape Sequences?</h3> <p>Unicode escape sequences represent characters using their hexadecimal code point values. The most common format is \uXXXX where XXXX is a 4-digit hex number. For characters outside the Basic Multilingual Plane (above U+FFFF), surrogate pairs like \uD83D\uDE00 are used for emoji and rare characters.</p> <h3>Where Unicode Escapes Are Used</h3> <p>JavaScript and JSON use \uXXXX escapes for non-ASCII characters in strings. Java uses the same format. Python uses \uXXXX for 16-bit and \UXXXXXXXX for 32-bit code points. HTML/XML uses &#xXXXX; numeric character references. Each has slightly different syntax but serves the same purpose.</p> <h3>Handling Emoji and Supplementary Characters</h3> <p>Emoji and characters above U+FFFF require special handling. In JavaScript/JSON, they're encoded as surrogate pairs - two \uXXXX sequences. For example, the emoji 😀 (U+1F600) becomes \uD83D\uDE00. This tool automatically handles surrogate pair encoding and decoding.</p> <h3>Use Cases for Unicode Escapes</h3> <p>Escape sequences ensure characters survive text processing that might corrupt non-ASCII bytes. They make international text portable in ASCII-only environments. Configuration files, source code, and data interchange formats often require escaped Unicode for reliability.</p> <h3>Debugging Character Issues</h3> <p>When text appears garbled or displays incorrectly, viewing the Unicode escapes reveals the actual code points. This helps identify encoding mismatches, invalid characters, or display font issues. Compare expected vs actual escape sequences to pinpoint problems.</p> <h3>JavaScript String Literals</h3> <p>In JavaScript, you can include any Unicode character using escapes: "Hello \u4E16\u754C" produces "Hello 世界". This is useful when your source file encoding might not support the character directly, or for clarity in code reviews.</p>

UTF-8 Encoder/Decoder

<p>The UTF-8 Encoder/Decoder shows you the exact byte sequences used to represent text in UTF-8 encoding. See how characters become bytes, understand multi-byte sequences for international characters, and diagnose encoding issues. UTF-8 is the dominant encoding for the modern web and software.</p> <h3>What Is UTF-8?</h3> <p>UTF-8 (Unicode Transformation Format - 8-bit) is a variable-length character encoding that can represent every Unicode character. ASCII characters use 1 byte, most Latin/European characters use 2 bytes, Asian characters use 3 bytes, and emoji/rare characters use 4 bytes. UTF-8 is backwards-compatible with ASCII.</p> <h3>UTF-8 Byte Patterns</h3> <p>UTF-8 uses specific bit patterns: single-byte characters start with 0, continuation bytes start with 10, and leading bytes indicate sequence length. A 2-byte sequence starts with 110, 3-byte with 1110, 4-byte with 11110. These patterns make UTF-8 self-synchronizing and error-detectable.</p> <h3>UTF-8 as the Web Standard</h3> <p>UTF-8 is the standard encoding for HTML5, JSON, XML, URLs, and most modern systems. Over 98% of web pages use UTF-8. If you're building web applications, UTF-8 should be your default choice for text handling everywhere.</p> <h3>Common UTF-8 Issues</h3> <p>Mojibake (garbled text) occurs when UTF-8 is interpreted as another encoding or vice versa. BOM (Byte Order Mark) at file start can cause issues in some contexts. Double-encoding happens when already-encoded bytes are encoded again. This tool helps identify these problems.</p> <h3>The BOM (Byte Order Mark)</h3> <p>The UTF-8 BOM is the sequence EF BB BF at the start of a file. While valid, it's generally unnecessary for UTF-8 and can cause problems with shell scripts, PHP files, and some parsers. The BOM is more important for UTF-16 where byte order matters.</p> <h3>Viewing Byte Sequences</h3> <p>Enter text to see its UTF-8 bytes in hexadecimal. "Hello" shows simple ASCII bytes: 48 65 6C 6C 6F. A Chinese character like "中" shows three bytes: E4 B8 AD. Understanding these patterns helps debug encoding issues in files and network protocols.</p>

ASCII Code Converter

<p>The ASCII Code Converter transforms characters to their ASCII numeric values and vice versa. See decimal, hexadecimal, octal, and binary representations of any ASCII character. Essential for understanding computer fundamentals, debugging character issues, and working with low-level data.</p> <h3>What Is ASCII?</h3> <p>ASCII (American Standard Code for Information Interchange) is a 7-bit character encoding standard from 1963. It defines 128 characters: 0-31 are control characters (tab, newline, etc.), 32-126 are printable characters (letters, digits, symbols), and 127 is DEL. ASCII became the foundation for modern character encodings.</p> <h3>ASCII Code Ranges</h3> <p>Control characters: 0-31 (NUL, TAB, LF, CR, etc.). Space: 32. Digits 0-9: 48-57. Uppercase A-Z: 65-90. Lowercase a-z: 97-122. Common symbols scattered throughout. Understanding these ranges helps with character manipulation and validation.</p> <h3>Multiple Number Representations</h3> <p>This tool shows ASCII codes in multiple bases: decimal (65 for 'A'), hexadecimal (41), octal (101), and binary (01000001). Different contexts use different representations - programming often uses hex, some languages use octal escapes.</p> <h3>Extended ASCII</h3> <p>Extended ASCII uses the 8th bit for characters 128-255, but there's no single standard - different systems define this range differently (ISO-8859-1, Windows-1252, etc.). For modern text, use UTF-8 which is ASCII-compatible for codes 0-127.</p> <h3>Control Characters</h3> <p>ASCII control characters (0-31) include TAB (9), LF/newline (10), CR/carriage return (13), and others used for device control and text formatting. Understanding these helps debug line ending issues and text processing problems.</p> <h3>ASCII in Programming</h3> <p>Programmers use ASCII values for character math ('A' + 32 = 'a' for case conversion), validation (checking if code 48-57 for digits), and creating character sequences. This fundamental knowledge applies across nearly all programming languages.</p>

Unicode Code Point Lookup

<p>The Unicode Code Point Lookup reveals detailed information about any character. Enter a character or code point to see its official Unicode name, code point (U+XXXX), UTF-8/UTF-16 encoding, script, category, and related characters. Essential for working with international text and understanding the Unicode standard.</p> <h3>What Is a Unicode Code Point?</h3> <p>A code point is a unique number assigned to each character in Unicode, written as U+ followed by hexadecimal digits. The letter A is U+0041, the Euro sign is U+20AC, and the grinning face emoji is U+1F600. Unicode currently defines over 149,000 characters across 161 scripts.</p> <h3>Unicode Character Properties</h3> <p>Each Unicode character has properties: General Category (letter, number, symbol, etc.), Script (Latin, Han, Arabic, etc.), Bidirectional class, and more. These properties help software correctly render, sort, and process text in any language.</p> <h3>Character Names</h3> <p>Every Unicode character has an official name. "A" is LATIN CAPITAL LETTER A. "€" is EURO SIGN. "😀" is GRINNING FACE. Names follow consistent patterns and help identify characters unambiguously. This tool shows official Unicode names.</p> <h3>Unicode Planes</h3> <p>Unicode is divided into planes of 65,536 code points each. Plane 0 (BMP - Basic Multilingual Plane) contains most common characters. Plane 1 contains emoji and historic scripts. Planes 2 and 3 contain rare CJK characters. This tool indicates which plane a character belongs to.</p> <h3>Confusable Characters</h3> <p>Unicode includes characters that look identical but have different code points - like Latin A (U+0041) and Cyrillic А (U+0410). These "confusables" or "homoglyphs" are used in phishing attacks. This tool can help identify the actual character when appearance is ambiguous.</p> <h3>Using Code Points</h3> <p>Search by entering a character directly, or by code point in various formats: U+1F600, 0x1F600, or just 1F600. The tool returns the character along with all its Unicode properties and encoding representations.</p>

Charset Converter

<p>The Charset Converter transforms text between different character encodings. Fix garbled text (Mojibake) by interpreting bytes in the correct encoding. Convert between UTF-8, ISO-8859-1 (Latin-1), Windows-1252, and other encodings. Essential for handling legacy data and debugging encoding issues.</p> <h3>Why Encoding Conversion Matters</h3> <p>Different systems use different character encodings. Legacy databases might use Latin-1. Old Windows files often use Windows-1252. Email might arrive in various encodings. When systems misinterpret encoding, text becomes garbled. This tool helps diagnose and fix these mismatches.</p> <h3>Common Encodings</h3> <p>UTF-8 is the modern standard, supporting all Unicode characters. ISO-8859-1 (Latin-1) covers Western European languages. Windows-1252 extends Latin-1 with smart quotes and other characters. ISO-8859-15 adds Euro sign and French characters. Shift-JIS and EUC cover Japanese text.</p> <h3>Fixing Mojibake</h3> <p>Mojibake is garbled text from encoding misinterpretation. For example, UTF-8 text read as Latin-1 shows "é" instead of "é". To fix it: interpret the garbled bytes as the wrong encoding, then convert to the correct one. This tool automates this process.</p> <h3>Encoding Detection</h3> <p>When you don't know the original encoding, look for patterns. UTF-8 has distinctive byte sequences. Latin-1 garbled as UTF-8 shows à followed by another character. The tool can suggest likely encodings based on byte patterns.</p> <h3>Converting Legacy Data</h3> <p>When migrating data from older systems, you often need to convert from legacy encodings to UTF-8. This tool helps verify the conversion is correct and identify any characters that might be lost or corrupted in translation.</p> <h3>Round-Trip Testing</h3> <p>Verify encoding handling by converting text through multiple encodings. If text survives the round trip unchanged, your encoding chain is working correctly. Characters that fail reveal encoding vulnerabilities in your system.</p>

AES Encrypt/Decrypt

<p>The AES Encrypt/Decrypt tool provides symmetric encryption using the Advanced Encryption Standard. AES is the gold standard for data encryption, used by governments and industries worldwide. Enter your plaintext and password to encrypt, or paste encrypted data to decrypt. All processing uses the browser's native Web Crypto API.</p> <h3>What Is AES?</h3> <p>AES (Advanced Encryption Standard) is a symmetric block cipher adopted by the U.S. government in 2001. It replaced DES as the standard symmetric encryption algorithm. AES encrypts data in 128-bit blocks using keys of 128, 192, or 256 bits. It's fast, secure, and has no known practical attacks.</p> <h3>How AES Encryption Works</h3> <p>AES performs multiple rounds of substitution and permutation on 128-bit data blocks. The number of rounds depends on key size: 10 rounds for 128-bit, 12 for 192-bit, 14 for 256-bit keys. Each round applies SubBytes, ShiftRows, MixColumns, and AddRoundKey operations. This creates strong diffusion and confusion.</p> <h3>Modes of Operation</h3> <p>Block ciphers like AES need a mode of operation for handling data longer than one block. GCM (Galois/Counter Mode) provides authenticated encryption and is recommended. CBC (Cipher Block Chaining) is common but requires separate authentication. This tool uses AES-GCM for both confidentiality and integrity.</p> <h3>Password-Based Key Derivation</h3> <p>Passwords are converted to encryption keys using PBKDF2 (Password-Based Key Derivation Function 2). This adds computational cost to prevent brute force attacks and uses salt to prevent rainbow table attacks. The derived key is then used for AES encryption.</p> <h3>Security Best Practices</h3> <p>Use strong, unique passwords for each encryption. AES-256 provides excellent security for sensitive data. Never reuse initialization vectors (IVs) - this tool generates random IVs for each encryption. Store encrypted data and keys/passwords separately.</p> <h3>Browser-Based Security</h3> <p>This tool uses the Web Crypto API for cryptographic operations. Your data and password never leave your browser. While convenient for testing and personal use, consider dedicated encryption software for highly sensitive data that might be compromised if your browser is compromised.</p>

ROT13 Cipher

<p>The ROT13 Cipher rotates letters by 13 positions in the alphabet. Because there are 26 letters, applying ROT13 twice returns the original text - making it perfectly symmetric for encoding and decoding. ROT13 is commonly used to obscure spoilers, puzzle answers, and mildly sensitive content online.</p> <h3>What Is ROT13?</h3> <p>ROT13 (rotate by 13 places) is a simple letter substitution cipher. A becomes N, B becomes O, and so on through the alphabet. Non-letter characters remain unchanged. Because the alphabet has 26 letters, ROT13 is its own inverse - encoding and decoding use the same operation.</p> <h3>ROT13 Is Not Encryption</h3> <p>ROT13 provides no real security. Anyone who recognizes ROT13 text can decode it instantly. It's not encryption - it's obfuscation. Think of it as the text equivalent of turning a page upside down. Use it for hiding spoilers, not protecting secrets.</p> <h3>Common Uses of ROT13</h3> <p>Online forums use ROT13 for spoilers and puzzle answers - readers can see something is hidden but won't accidentally read it. Email addresses are sometimes ROT13-encoded to hide from simple spam harvesters. Some programming contests use ROT13 for hidden test cases.</p> <h3>ROT13 in Internet Culture</h3> <p>ROT13 became popular on Usenet in the 1980s for hiding spoilers in discussion groups. The phrase "ROT13" is often written as "EBG13" (itself ROT13-encoded). The encoding has been part of internet culture for decades as a lighthearted way to hide content.</p> <h3>The Self-Inverse Property</h3> <p>ROT13 is unique among ROT ciphers because it's self-inverse. ROT5 for digits would need ROT5 again to decode. ROT7 would need ROT19. But ROT13 applied twice always returns the original. This makes it especially convenient - one operation for both directions.</p> <h3>ROT13 vs Caesar Cipher</h3> <p>ROT13 is a specific case of the Caesar cipher with shift=13. The Caesar cipher uses any shift from 1-25. ROT13's self-inverse property makes it special. Historically, Caesar reportedly used shift=3, but any shift creates a similar (and similarly weak) cipher.</p>

Caesar Cipher

<p>The Caesar Cipher shifts each letter by a specified number of positions in the alphabet. Named after Julius Caesar who reportedly used it for military messages, this ancient cipher is the foundation of modern cryptography education. Choose any shift from 1-25 to encode or decode messages.</p> <h3>History of the Caesar Cipher</h3> <p>Julius Caesar used this cipher around 50 BCE to protect military communications. According to Suetonius, Caesar used a shift of 3 (A→D, B→E, etc.). While easily broken today, it was effective in an era when most people were illiterate and substitution ciphers were unknown.</p> <h3>How the Cipher Works</h3> <p>Each letter is replaced by the letter a fixed number of positions down the alphabet. With shift=3: A becomes D, B becomes E, Z wraps around to C. Decryption uses the same shift in reverse (or equivalently, 26 minus the shift forward).</p> <h3>Breaking the Caesar Cipher</h3> <p>With only 25 possible keys, Caesar cipher is trivially broken by brute force - try all shifts until one produces readable text. Frequency analysis also works: 'E' is the most common English letter, so the most frequent ciphertext letter likely represents 'E'.</p> <h3>Educational Value</h3> <p>The Caesar cipher teaches fundamental cryptographic concepts: substitution, keys, encryption/decryption symmetry, and why simple ciphers fail. It's an excellent introduction before studying Vigenère, Enigma, and modern cryptography.</p> <h3>Variations and Extensions</h3> <p>ROT13 is Caesar cipher with shift=13. Affine cipher generalizes substitution with multiplication. Vigenère uses multiple Caesar ciphers with a keyword. Each improvement addressed Caesar's weaknesses while maintaining the substitution principle.</p> <h3>Modern "Uses"</h3> <p>Caesar cipher has no legitimate security use today. It appears in puzzles, escape rooms, geocaching, CTF challenges, and educational contexts. Recognizing and solving Caesar ciphers is a basic skill in puzzle-solving communities.</p>

Vigenere Cipher

<p>The Vigenere Cipher uses a keyword to create multiple shifting alphabets, making it far stronger than the simple Caesar cipher. For centuries it was considered unbreakable, earning the nickname "le chiffre indéchiffrable" (the indecipherable cipher). Though eventually broken, it remains an important milestone in cryptographic history.</p> <h3>How Vigenere Works</h3> <p>Each letter of the keyword defines a different Caesar shift for the corresponding plaintext letter. With keyword "KEY", the first letter uses K's shift (10), second uses E's shift (4), third uses Y's shift (24), then the pattern repeats. This polyalphabetic approach defeats simple frequency analysis.</p> <h3>The Vigenere Table</h3> <p>The cipher uses a 26×26 table (tabula recta) where each row is the alphabet shifted by one position. To encrypt, find the plaintext letter's column and keyword letter's row - the intersection is the ciphertext. Decryption reverses this process.</p> <h3>Historical Significance</h3> <p>Giovan Battista Bellaso first described the cipher in 1553, but Blaise de Vigenère's name became attached to it. For 300 years it resisted cryptanalysis. Charles Babbage (and later Friedrich Kasiski) finally broke it in the 1850s using patterns in repeated keyword letters.</p> <h3>Breaking Vigenere: Kasiski Examination</h3> <p>When the same plaintext appears at intervals matching the keyword length, identical ciphertext results. Finding these repeated sequences reveals the likely keyword length. Once the length is known, the cipher becomes multiple Caesar ciphers that can be solved with frequency analysis.</p> <h3>Keyword Selection</h3> <p>Longer keywords are more secure. Random keywords resist dictionary attacks. Never use obvious keywords (names, dates, common words). However, remember that Vigenere with any keyword is still insecure by modern standards - use proper encryption for real security.</p> <h3>Educational Value</h3> <p>Vigenere introduces polyalphabetic substitution - a major advancement over Caesar. It demonstrates why simple substitution fails and why key length matters. Understanding Vigenere helps appreciate the sophistication of modern cryptography.</p>

XOR Cipher

<p>The XOR Cipher applies the exclusive-or operation between plaintext and a key. XOR is fundamental to cryptography - it's self-inverse (applying XOR twice with the same key returns the original), provides perfect secrecy with truly random one-time keys, and forms the basis of stream ciphers and many encryption algorithms.</p> <h3>What Is XOR?</h3> <p>XOR (exclusive or) is a binary operation: 0⊕0=0, 0⊕1=1, 1⊕0=1, 1⊕1=0. In simple terms, the output is 1 when inputs differ. Applied to bytes, XOR operates on each bit independently. The critical property: A⊕B⊕B=A - XORing with the same value twice returns the original.</p> <h3>Self-Inverse Property</h3> <p>XOR's self-inverse nature makes it perfect for symmetric encryption. Encrypt by XORing plaintext with key. Decrypt by XORing ciphertext with the same key. No separate encrypt/decrypt operations needed - one operation serves both purposes.</p> <h3>The One-Time Pad</h3> <p>XOR with a truly random key as long as the message creates a one-time pad - the only cipher with mathematically proven perfect secrecy. Every possible plaintext is equally likely given the ciphertext. The catch: the key must be truly random, as long as the message, and never reused.</p> <h3>Why Key Reuse Is Fatal</h3> <p>If you XOR two messages with the same key: C1⊕C2 = (P1⊕K)⊕(P2⊕K) = P1⊕P2. The key cancels out, revealing the XOR of the plaintexts. With enough reuse, attackers can recover messages. This is why one-time pads must truly be one-time.</p> <h3>XOR in Modern Cryptography</h3> <p>Stream ciphers (RC4, ChaCha20) generate keystreams that are XORed with plaintext. Block cipher modes like CTR use XOR. AES itself uses XOR in its AddRoundKey step. XOR is a building block, not a complete solution - it needs proper key management.</p> <h3>XOR for Obfuscation</h3> <p>Simple XOR with a short repeating key is easily broken but still used for basic obfuscation - malware often XOR-encodes strings to evade simple detection. This is security through obscurity and provides no real protection against analysis.</p>

Binary/Decimal Converter

<p>The Binary/Decimal Converter transforms numbers between the binary number system (base 2) and decimal (base 10). Binary is the foundation of digital computing - every piece of data in computers is ultimately stored as binary. Understanding binary helps with programming, debugging, and grasping how computers work.</p> <h3>What Is Binary?</h3> <p>Binary is the base-2 number system using only digits 0 and 1 (called bits). Each position represents a power of 2: from right to left, 1, 2, 4, 8, 16, 32, etc. The binary number 1101 equals 8+4+0+1=13 in decimal. This matches how electronic circuits have two states: on and off.</p> <h3>Converting Binary to Decimal</h3> <p>Multiply each bit by its position value (power of 2) and sum. For 1101: (1×8)+(1×4)+(0×2)+(1×1) = 13. The rightmost bit is position 0 (2^0=1), then position 1 (2^1=2), and so on.</p> <h3>Converting Decimal to Binary</h3> <p>Repeatedly divide by 2 and record remainders from bottom to top. For 13: 13÷2=6r1, 6÷2=3r0, 3÷2=1r1, 1÷2=0r1. Reading remainders upward: 1101. Alternatively, subtract the largest power of 2 that fits, mark that bit as 1, and repeat.</p> <h3>Binary in Computing</h3> <p>Computers use binary because electronic circuits reliably distinguish two states (high/low voltage). 8 bits make a byte (256 values). 32-bit integers reach ~4 billion. 64-bit integers reach astronomical values. Understanding binary helps with bitwise operations, memory addresses, and file sizes.</p> <h3>Common Binary Values</h3> <p>Programmers memorize key values: 1024 = 2^10, 255 = 11111111 (max byte), 65535 = max unsigned 16-bit. Powers of 2 appear everywhere in computing: memory sizes, color depth, address spaces. Binary fluency is a programmer's skill.</p> <h3>Signed Numbers and Two's Complement</h3> <p>Negative numbers in binary use two's complement. The leading bit indicates sign (1 = negative). To negate: flip all bits and add 1. This allows addition and subtraction to work the same way for positive and negative numbers.</p>

Hex/Decimal Converter

<p>The Hex/Decimal Converter transforms numbers between hexadecimal (base 16) and decimal (base 10). Hexadecimal is ubiquitous in programming - used for colors (#FF5733), memory addresses (0x7FFF), byte values, and more. It's the perfect middle ground between binary (too long) and decimal (doesn't align with bytes).</p> <h3>What Is Hexadecimal?</h3> <p>Hexadecimal uses 16 digits: 0-9 plus A-F (representing 10-15). Each hex digit represents exactly 4 binary bits, so one byte (8 bits) becomes two hex digits. This makes hex perfect for representing binary data compactly. Decimal 255 is FF in hex and 11111111 in binary.</p> <h3>Converting Hex to Decimal</h3> <p>Multiply each digit by 16 raised to its position (rightmost is position 0). A=10, B=11, C=12, D=13, E=14, F=15. For FF: (15×16)+(15×1) = 240+15 = 255. For 2A3: (2×256)+(10×16)+(3×1) = 675.</p> <h3>Converting Decimal to Hex</h3> <p>Repeatedly divide by 16 and record remainders. Convert remainders 10-15 to A-F. For 255: 255÷16=15r15, 15÷16=0r15. Remainders 15,15 = F,F. Result: FF.</p> <h3>Hexadecimal in Programming</h3> <p>Code uses 0x prefix for hex (0xFF = 255). CSS colors use hex (#RGB or #RRGGBB). Memory addresses display in hex. MAC addresses are hex. Unicode code points use hex (U+1F600). Debug tools show hex dumps.</p> <h3>Why Hex Aligns with Binary</h3> <p>16 = 2^4, so each hex digit is exactly 4 bits. A byte (8 bits) is always 2 hex digits. This clean mapping makes conversion trivial and makes hex ideal for representing binary data. Decimal has no such alignment.</p> <h3>Common Hex Values</h3> <p>FF = 255 (max byte). FFFF = 65535 (max 16-bit). FFFFFFFF = max 32-bit. Programmers know these instinctively. Colors like FF0000 (red), 00FF00 (green), 0000FF (blue) show the byte-based structure clearly.</p>

Octal Converter

<p>The Octal Converter transforms numbers between octal (base 8) and other bases. Octal uses digits 0-7 and was historically important in computing. Today it's primarily used for Unix file permissions and some legacy systems. Each octal digit represents exactly 3 binary bits.</p> <h3>What Is Octal?</h3> <p>Octal is the base-8 number system using digits 0 through 7. Like hexadecimal aligns with 4 bits, octal aligns with 3 bits. The octal number 755 equals 111 101 101 in binary, which is why it's used for Unix permissions (rwx for owner, rx for group and others).</p> <h3>Unix File Permissions</h3> <p>The most common octal use today is Unix permissions. Each digit represents rwx (read=4, write=2, execute=1). Permission 644 means rw- for owner (6=4+2), r-- for group and others (4). Permission 755 means rwx for owner, rx for others.</p> <h3>Why Octal for Permissions?</h3> <p>Unix permissions are 9 bits: 3 each for owner, group, others. Three bits perfectly represent one octal digit. So 9 permission bits become 3 octal digits. This made permission representation compact and memorable.</p> <h3>Octal in Programming</h3> <p>Some languages use octal literals with 0 prefix: 0755 in C. This can cause bugs when numbers accidentally start with 0. JavaScript's parseInt("08") historically failed because 08 isn't valid octal. Modern code avoids octal except for permissions.</p> <h3>Converting Octal</h3> <p>To decimal: multiply each digit by 8^position. For 755: (7×64)+(5×8)+(5×1) = 448+40+5 = 493. To binary: convert each octal digit to 3 bits. 755 → 111 101 101.</p> <h3>Octal History</h3> <p>Early computers used 6-bit or 12-bit words, which align with octal. PDP-8 and other historic machines used octal in documentation and dumps. Hexadecimal became dominant with 8-bit bytes, but octal persists in Unix culture.</p>

Roman Numeral Converter

<p>The Roman Numeral Converter transforms between Roman numerals (I, V, X, L, C, D, M) and Arabic numbers. Roman numerals are still used for clocks, outlines, movie sequels, building dates, and formal contexts. Understanding the conversion rules helps read and write them correctly.</p> <h3>Roman Numeral Basics</h3> <p>Seven symbols form all Roman numerals: I=1, V=5, X=10, L=50, C=100, D=500, M=1000. Numbers are formed by combining symbols. Generally, add values when symbols decrease left to right (VI=6). Subtract when a smaller symbol precedes a larger one (IV=4).</p> <h3>Subtractive Notation Rules</h3> <p>Only certain subtractions are valid: I before V or X (IV=4, IX=9), X before L or C (XL=40, XC=90), C before D or M (CD=400, CM=900). You cannot write VL for 45 - use XLV instead. These rules keep representation unambiguous.</p> <h3>Forming Numbers</h3> <p>Write the largest possible symbol first, then continue with remaining value. For 1984: M (1000) + CM (900) + LXXX (80) + IV (4) = MCMLXXXIV. The same principle works in reverse for reading Roman numerals.</p> <h3>Extended Notation for Large Numbers</h3> <p>Standard Roman numerals typically go up to 3,999 (MMMCMXCIX). For larger numbers, overlines indicate multiplication by 1000: V̄ = 5,000, X̄ = 10,000. Some systems use different brackets or symbols for extension.</p> <h3>Modern Uses</h3> <p>Clock faces (IV or IIII for 4), book chapters and outlines (I, II, III), movie sequels (Rocky IV), royal names (Queen Elizabeth II), building cornerstone dates (MCMXLV = 1945), and Super Bowl numbers (Super Bowl LVIII).</p> <h3>Common Mistakes</h3> <p>Never repeat V, L, or D - use the next higher symbol. Never repeat a symbol more than 3 times (IIII is wrong except on clock faces traditionally). Always use subtractive notation where applicable (4 is IV, not IIII).</p>

Base Converter (Any Base)

<p>The Base Converter transforms numbers between any bases from 2 to 36. Beyond the common binary (2), octal (8), decimal (10), and hexadecimal (16), explore base 36 (using all digits and letters), base 3 (ternary), or any other base. Perfect for learning about positional number systems.</p> <h3>How Positional Systems Work</h3> <p>In base N, digits range from 0 to N-1. Each position represents a power of N: rightmost is N^0=1, then N^1, N^2, etc. Base 10 uses powers of 10 (1, 10, 100...). Base 2 uses powers of 2 (1, 2, 4, 8...). The principle is identical across all bases.</p> <h3>Base 36: Maximum Standard Base</h3> <p>Base 36 uses 0-9 and A-Z, totaling 36 symbols. It's the largest base using alphanumeric characters. Used in some URL shorteners and compact identifiers. Base 36 "Z" equals decimal 35, "10" equals decimal 36.</p> <h3>Common Bases in Computing</h3> <p>Binary (2): fundamental to electronics. Octal (8): Unix permissions. Decimal (10): human standard. Hexadecimal (16): bytes and colors. Base 64 exists but uses different encoding conventions (not positional).</p> <h3>Unusual Bases</h3> <p>Ternary (base 3) was used in some early computers. Balanced ternary uses -1, 0, +1. Base 12 (duodecimal) has advocates for its divisibility. Base 60 (sexagesimal) persists in time (60 seconds, 60 minutes) from Babylonian times.</p> <h3>Converting Between Bases</h3> <p>The common method: first convert source to decimal, then convert decimal to target base. Mathematically, multiply digits by source base powers for step 1, then repeatedly divide by target base for step 2.</p> <h3>Educational Value</h3> <p>Working with multiple bases builds deep understanding of number representation. It clarifies why hexadecimal and binary relate so well, and why decimal has no special mathematical significance - just familiarity.</p>

QR Code Generator

<p>The QR Code Generator creates scannable QR codes from URLs, text, WiFi credentials, contact cards, and more. Customize colors, size, and error correction. Download in PNG or SVG format. QR codes bridge physical and digital - print them anywhere for instant access to your content.</p> <h3>What Is a QR Code?</h3> <p>QR (Quick Response) codes are two-dimensional barcodes that store data in a pattern of black and white squares. Developed by Denso Wave in 1994 for tracking automotive parts, QR codes can encode thousands of characters and are readable from any angle. They've become ubiquitous for sharing URLs, payments, and contact info.</p> <h3>Data Types for QR Codes</h3> <p>URLs are most common - scan to visit a website. WiFi credentials (SSID, password, encryption type) let guests join networks easily. vCard format shares contact information. SMS and email links pre-fill messages. Plain text for any arbitrary data. Each type has specific formatting that apps recognize.</p> <h3>Error Correction Levels</h3> <p>QR codes include redundant data for error correction. Level L recovers 7% damage, M recovers 15%, Q recovers 25%, H recovers 30%. Higher correction means larger codes but better reliability. Use H for codes that might be partially obscured or damaged.</p> <h3>Size and Scanning</h3> <p>QR codes must be large enough to scan reliably. Minimum size depends on scanning distance and content complexity. A simple URL might need 2cm for close scanning. Billboards need much larger codes. More data requires more modules, limiting minimum size.</p> <h3>Customization Options</h3> <p>Change foreground and background colors (ensure sufficient contrast). Add logos in the center (use high error correction). Adjust module size and quiet zone. Some customizations reduce scannability - always test. Dark-on-light works best for most scanners.</p> <h3>Best Practices</h3> <p>Keep URLs short or use URL shorteners. Test with multiple devices before printing. Include a quiet zone (white border). Don't over-customize at the expense of reliability. For permanent installations, ensure the linked content will persist.</p>

QR Code Decoder

<p>The QR Code Decoder extracts data from QR code images. Upload an image or paste from clipboard to decode URLs, text, WiFi credentials, and other embedded data. Useful for inspecting suspicious QR codes before scanning with your phone, recovering encoded information, and analyzing QR code contents.</p> <h3>Why Decode QR Codes Manually?</h3> <p>Phone cameras decode QR codes but often immediately act on the content - opening URLs, joining WiFi, etc. Manual decoding lets you inspect the data first. See exactly where a URL leads before visiting. Verify WiFi credentials. Check for malicious content before scanning with your phone.</p> <h3>QR Code Security</h3> <p>Malicious QR codes can link to phishing sites, malware downloads, or unexpected actions. Before scanning unknown codes (found on stickers, posters, or untrusted sources), decode them first to inspect the URL. Legitimate codes from trusted sources are generally safe.</p> <h3>How Decoding Works</h3> <p>The decoder locates the three position patterns (large squares in corners), reads the format information, determines the encoding mode, applies error correction, and extracts the payload. This happens client-side using JavaScript image processing - no server uploads.</p> <h3>Supported Formats</h3> <p>Upload JPG, PNG, GIF, or other image formats. The decoder handles images with the QR code anywhere in frame - it doesn't need to fill the entire image. Some noise and distortion is tolerable depending on error correction level.</p> <h3>Troubleshooting Decode Failures</h3> <p>If decoding fails: ensure the image is clear and in focus, the QR code is complete (not cut off), there's sufficient contrast, and the image isn't too small. Try taking a clearer photo. Severely damaged codes may not decode even with high error correction.</p> <h3>Webcam Scanning</h3> <p>Some versions of this tool support webcam input for live scanning. Position the QR code in view, and decoding happens automatically. This mirrors phone scanning but shows you the data instead of acting on it.</p>

Barcode Generator

<p>The Barcode Generator creates linear barcodes in multiple formats including Code128, EAN-13, EAN-8, UPC-A, UPC-E, Code39, ITF-14, and more. Select the appropriate format for your use case, enter your data, and download the barcode image for printing or digital use.</p> <h3>Understanding Barcode Formats</h3> <p>Different industries use different formats. EAN-13 and UPC-A are retail product codes. Code128 handles alphanumeric data efficiently. Code39 is common in manufacturing. ITF-14 is for shipping cartons. Each format has specific character sets, lengths, and check digit requirements.</p> <h3>Code128: Most Versatile</h3> <p>Code128 encodes all 128 ASCII characters compactly. It's ideal for inventory, shipping labels, and any alphanumeric data. Three subsets (A, B, C) optimize encoding for different character types. Most scanners support Code128, making it a safe default choice.</p> <h3>EAN-13: Retail Products</h3> <p>European Article Number (EAN-13) is the international standard for retail products. It consists of 13 digits including country code, manufacturer, product, and check digit. North American UPC-A is a subset of EAN-13. Use for products sold in stores.</p> <h3>UPC-A and UPC-E</h3> <p>UPC-A uses 12 digits and is standard in North America. UPC-E is a compressed 8-digit version for small packages. Both are compatible with EAN systems. These are assigned by GS1 for commercial products - don't use random numbers for actual products.</p> <h3>Code39: Industrial Use</h3> <p>Code39 encodes uppercase letters, digits, and some symbols. It's self-checking (no required check digit). Common in automotive, defense, and healthcare. Less compact than Code128 but widely supported by older systems.</p> <h3>Check Digits</h3> <p>Most formats include check digits calculated from the data for error detection. This tool automatically calculates check digits. Don't add your own check digit - the generator handles it. Invalid check digits will cause scan failures.</p>

UUID Generator

<p>The UUID Generator creates Universally Unique Identifiers - 128-bit values guaranteed to be unique across space and time. UUIDs are essential for distributed systems, database primary keys, API references, and any application needing identifiers without central coordination.</p> <h3>What Is a UUID?</h3> <p>A UUID (Universally Unique Identifier) is a 128-bit number, typically displayed as 32 hexadecimal digits in the format xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx. Also called GUID (Globally Unique Identifier) in Microsoft ecosystems. The standard ensures IDs are unique without central authority.</p> <h3>UUID Version 4: Random</h3> <p>Version 4 UUIDs are generated from random or pseudo-random numbers. They have 122 random bits, providing 5.3×10^36 possible values. Collision probability is astronomically small - you could generate a billion per second for a century and likely never collide.</p> <h3>UUID Version 1: Timestamp-Based</h3> <p>Version 1 combines timestamp and MAC address. Guarantees uniqueness through time and machine. Reveals generation time and source machine, which may be a privacy concern. Useful when ordering by ID should reflect creation order.</p> <h3>UUID Version 7: Modern Timestamp</h3> <p>Version 7 (RFC 9562) uses Unix timestamp in milliseconds plus random bits. IDs are sortable by creation time, improving database index performance. Becoming the recommended choice for new applications needing sorted, unique IDs.</p> <h3>UUIDs as Database Keys</h3> <p>UUIDs enable distributed ID generation without coordination. Each node can create IDs independently. However, random UUIDs have poor database index locality. Consider UUID v7 or ULIDs for better performance with ordered insertion.</p> <h3>Alternative: ULID and Others</h3> <p>ULID (Universally Unique Lexicographically Sortable Identifier) combines timestamp and randomness in a sortable format. Snowflake IDs (Twitter) and KSUID also solve the sorted-unique-ID problem. Each has tradeoffs in size, sortability, and encoding.</p>

Morse Code Translator

<p>The Morse Code Translator converts between text and Morse code (dots and dashes). Morse code was essential for early long-distance communication and remains relevant in emergency situations, amateur radio, and cultural references. This tool encodes text to Morse and decodes Morse back to text.</p> <h3>What Is Morse Code?</h3> <p>Morse code represents letters and numbers as sequences of short signals (dots, .) and long signals (dashes, -). Developed by Samuel Morse in the 1830s for telegraph communication, it revolutionized long-distance communication. The code is designed so common letters (E, T) have short codes.</p> <h3>International Morse Code Standard</h3> <p>The international standard assigns specific patterns to each character. E is a single dot (.). T is a single dash (-). Letters vary from 1 to 4 symbols. Numbers are 5 symbols. Space between letters is typically 3 time units, between words is 7 time units.</p> <h3>Morse Code Timing</h3> <p>A dot is 1 time unit. A dash is 3 units. Gap between symbols in a letter is 1 unit. Gap between letters is 3 units. Gap between words is 7 units. Speed is measured in words per minute (WPM), using "PARIS" as the standard word.</p> <h3>Learning Morse Code</h3> <p>Common techniques include the Koch method (learning at full speed, adding characters gradually) and Farnsworth timing (full-speed characters with extended spacing). Amateur radio operators still learn Morse, though it's no longer required for licensing in most countries.</p> <h3>Modern Uses</h3> <p>Amateur (ham) radio operators use Morse for long-distance communication. Aviation and maritime have Morse-based signals. SOS (...---...) remains the international distress signal. Some accessibility devices allow blinking Morse input. It appears in movies and puzzles.</p> <h3>Audio Playback</h3> <p>Some versions of this tool include audio playback of Morse code. Hearing the rhythm helps understand the timing and can aid learning. The characteristic sound of Morse adds to its nostalgic appeal.</p>