Developer-Tools | Toolbox Guides & Articles

HTTP Security Headers: A Practical Hardening Guide for CSP, HSTS, and Cross-Origin Isolation

Sun, 06 Sep 2026 00:00:00 +0000

Interactive Workbench LIVE

HTTP Security Headers: A Practical Hardening Guide for CSP, HSTS, and Cross-Origin Isolation

Open Fullscreen ↗

Initializing Workbench...

100% Client-Side RAM Sandbox

🔒 Private Execution: Computations run in local browser memory. Zero server uploads. Zero server uploads.

Launch Fullscreen →

Free In-Browser Tool TOOLBOX UTILITY

HTTP Header Security Auditor

Paste a raw response, get an A+ to F hardening grade with per-header findings, and export a matching Nginx or Apache configuration snippet.

Audit Your HTTP Headers →

Headers Are the Cheapest Security You Will Ever Deploy

Most web hardening work requires code changes, reviews, and regression testing. Security headers require a configuration line at the edge and cost nothing at runtime.

They are also the layer most often left at framework defaults — which is why a first audit of a mature application so often returns a grade of D or F.

The table below is the shortlist. Everything after it is detail.

Header	Blocks	Priority
`Content-Security-Policy`	Cross-site scripting, data injection	Critical
`Strict-Transport-Security`	Protocol downgrade, SSL stripping	Critical
`X-Content-Type-Options`	MIME-sniffing confusion attacks	Critical
`frame-ancestors` / `X-Frame-Options`	Clickjacking, UI redress	High
`Referrer-Policy`	URL and token leakage via `Referer`	High
`Permissions-Policy`	Unwanted camera, mic, geolocation access	Medium
`COOP` / `COEP` / `CORP`	Cross-origin leaks; enables isolation	Situational
`Cache-Control: no-store`	Sensitive data cached on shared devices	Situational

Content-Security-Policy: The One That Does the Work

CSP tells the browser which sources of script, style, and other content are legitimate. Done properly, it turns a cross-site scripting bug from a full account takeover into a blocked console error.

The Modern Strict Policy

Content-Security-Policy:
 default-src 'self';
 script-src 'nonce-{RANDOM}' 'strict-dynamic' https: 'unsafe-inline';
 object-src 'none';
 base-uri 'self';
 frame-ancestors 'none';
 require-trusted-types-for 'script';

Each line earns its place:

'nonce-{RANDOM}' — a fresh, cryptographically random value of at least 128 bits, generated per response and echoed on every legitimate <script nonce="...">. A reused or predictable nonce is no protection at all.
'strict-dynamic' — lets a nonce-approved script load further scripts it creates programmatically, and causes host allowlists to be ignored. This matters because allowlist-based policies are routinely bypassable through JSONP endpoints and open redirects on allowlisted CDNs.
https: 'unsafe-inline' — a deliberate fallback for browsers too old to understand nonces. Modern browsers ignore 'unsafe-inline' whenever a nonce or hash is present, which is specified behaviour, so this line is backward compatibility rather than a hole.
object-src 'none' — removes the <object>, <embed>, and legacy plugin bypass surface. There is almost never a reason to allow it.
base-uri 'self' — prevents an injected <base> tag from redirecting every relative URL on the page to an attacker’s host.
frame-ancestors 'none' — the modern clickjacking control, superseding X-Frame-Options.

Roll It Out in Report-Only Mode First

Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report;

The Report-Only variant logs violations without blocking anything. Run it for a full traffic cycle — including whatever nightly and monthly jobs render pages — before switching to the enforcing header. Deploying an untested CSP straight to enforcement is the fastest way to take your own site down.

Directives That Do Not Behave as Expected

default-src is not a universal fallback. It does not cover base-uri, frame-ancestors, form-action, or sandbox. Set those explicitly.
'unsafe-eval' re-enables eval and the string form of setTimeout. Some older bundlers and templating libraries need it; treat needing it as technical debt.
A meta http-equiv CSP silently drops frame-ancestors, report-uri, and sandbox, and only applies from the point the parser reads the tag. Send CSP as a real header.

Strict-Transport-Security

HSTS (RFC 6797) instructs the browser to refuse plaintext HTTP for a host for a fixed period — closing the window in which a first plaintext request can be intercepted and stripped.

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Token	Meaning	Notes
`max-age`	Seconds to remember the HTTPS-only rule	Required. 63072000 = two years
`includeSubDomains`	Applies to every subdomain	Verify every subdomain serves HTTPS first
`preload`	Requests inclusion in browser preload lists	Not part of RFC 6797; see hstspreload.org

Preload eligibility, per hstspreload.org, requires a valid certificate, an HTTP-to-HTTPS redirect on the same host, and a header on the HTTPS root with max-age of at least 31536000 plus both includeSubDomains and preload.

Two operational warnings:

Preloading is hard to undo. Removal requests take effect only as browsers ship new versions, which can mean months. A subdomain that cannot serve HTTPS becomes unreachable for users whose browsers hold the preload entry.
Ramp max-age upward. Start at 300, then a day, then a week, then a year. A mistake at max-age=63072000 is a two-year commitment for every visitor who received it.

HSTS is only sent over HTTPS. Browsers ignore it on a plaintext response, by design.

Clickjacking, Sniffing, and Referrer Leakage

`X-Content-Type-Options: nosniff`

One value, no options, no downside. It stops the browser from second-guessing your Content-Type, which is what turns an uploaded .txt file containing markup into stored XSS. Send it on every response.

`X-Frame-Options`

X-Frame-Options: DENY # or SAMEORIGIN

Defined in RFC 7034 and superseded by CSP frame-ancestors. Note that the ALLOW-FROM value was never implemented by Chrome or Safari — to permit a specific external framer, you must use frame-ancestors https://partner.example. Sending both headers is common and harmless, as long as they do not contradict each other.

`Referrer-Policy`

Referrer-Policy: strict-origin-when-cross-origin

This is now the browser default in Chrome and Firefox, but sending it explicitly documents the intent and protects against a proxy or framework overriding it. Cross-origin requests then carry only the origin — no path, no query string, no accidental token disclosure. Use no-referrer for pages whose URLs are themselves sensitive, such as password-reset links.

`Permissions-Policy`

Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=()

An empty allowlist () denies the feature to the document and every frame it embeds. Deny what you do not use — a third-party script in an iframe cannot prompt for a camera it has no permission to request. This header replaces the older Feature-Policy, which used a different value syntax.

Cross-Origin Isolation: COOP, COEP, CORP

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Resource-Policy: same-origin

COOP same-origin severs the window.opener relationship with cross-origin pages, closing a family of tab-nabbing and cross-window attacks.
COEP require-corp requires every cross-origin subresource to opt in explicitly, via CORS or Cross-Origin-Resource-Policy.
CORP is the opt-in mechanism resources use to declare who may embed them.

COOP plus COEP together put the document in a cross-origin isolated state, which is a prerequisite for SharedArrayBuffer and high-resolution timers. That makes them mandatory for WebAssembly-heavy applications — and also the pair most likely to break third-party embeds. COOP alone is a safe, valuable default; adopt COEP only when you need isolation and have audited every embedded resource.

Headers to Delete

Hardening is subtraction as well as addition.

Header	Action	Reason
`X-XSS-Protection`	Remove	The Chrome XSS Auditor it controlled was removed; the filter itself introduced information-leak bugs. OWASP advises against it.
`X-Powered-By`	Remove	Discloses runtime and version, handing an attacker a CVE shortlist
`Server`	Minimise	`Apache/2.4.41 (Ubuntu)` names the exact patch level to target
`X-AspNet-Version`	Remove	Same disclosure problem
`Public-Key-Pins`	Remove	HPKP is obsolete and removed from browsers; use Certificate Transparency and CAA records

Also remember Cache-Control: no-store on any authenticated response. A shared or kiosk browser retaining an account page in its back-forward cache is a real disclosure, and no-cache alone does not prevent storage.

Server Configuration Pitfalls

Nginx: inheritance and error responses

add_header Content-Security-Policy "default-src 'self'" always;
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;

Two behaviours cause almost every “header missing on some pages” report:

add_header directives are not merged across levels. A single add_header inside a location block discards all inherited add_header directives from server and http. Repeat the full set in that block.
Without always, headers are only added to successful responses. Your 404 and 500 pages ship unprotected — and those are exactly the pages most likely to reflect user input.

Apache

Header always set Content-Security-Policy "default-src 'self'"
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains"
Header always set X-Content-Type-Options "nosniff"
Header always unset X-Powered-By

Header always set is the equivalent of Nginx’s always, covering error responses too.

A Note on CORS

Access-Control-Allow-Origin is not a hardening header — it relaxes the same-origin policy. And Access-Control-Allow-Origin: * cannot be combined with Access-Control-Allow-Credentials: true; browsers reject that pairing. Reflecting an arbitrary Origin header back while allowing credentials is a serious vulnerability, not a configuration convenience.

Step-by-Step: Auditing with Toolbox

Capture your real headers. Run curl -sSI https://yoursite.example or copy the response headers from your browser’s Network panel.
Open the tool: visit the .
Paste the raw response into the input box, or start from one of the built-in presets to see what a hardened and an unhardened response look like side by side.
Read the Audit tab for the letter grade from A+ to F and the per-header findings behind it.
Check the Table tab for the parsed name-value view, which is the quickest way to spot a duplicated or malformed header.
Export from the Config tab — select Nginx or Apache and copy the generated hardening snippet straight into your server or edge configuration.
Re-audit after deploying, and check a 404 as well as a 200. Missing headers on error responses is the single most common regression.

Parsing and grading happen entirely in your browser; the tool never fetches your site or transmits the headers you paste. That means you can safely audit a staging environment behind a VPN, or a response containing session cookies.

Two related hardening steps sit just outside the header layer: verifying that inbound webhooks are genuinely signed, covered in the , and validating token claims properly, covered in the .

FAQ

Frequently Asked Questions

Which HTTP security headers actually matter most? ▼

Four carry most of the value. Content-Security-Policy limits which scripts can execute and is the primary defence against cross-site scripting. Strict-Transport-Security forces HTTPS and prevents downgrade attacks. X-Content-Type-Options with the value nosniff stops MIME confusion attacks. Either CSP frame-ancestors or X-Frame-Options prevents clickjacking. Referrer-Policy and Permissions-Policy are valuable but reduce data leakage rather than blocking an active attack.

Why is unsafe-inline ignored in my Content-Security-Policy? ▼

That behaviour is specified, not a bug. When a directive contains a nonce or a hash source expression, the browser ignores unsafe-inline for that directive. The design intent is that a page can send unsafe-inline as a fallback for very old browsers while modern browsers enforce the stricter nonce-based policy. If you want inline scripts to run in a modern browser, you must give each one the matching nonce or hash.

What does HSTS preload require? ▼

To be accepted onto the browser preload list at hstspreload.org, a site must serve a valid certificate, redirect all HTTP traffic to HTTPS on the same host, and send a Strict-Transport-Security header on the HTTPS root with a max-age of at least 31536000 seconds, plus the includeSubDomains and preload tokens. Preloading is difficult to reverse quickly, so confirm that every subdomain can serve HTTPS before submitting.

Is X-Frame-Options still needed if I use CSP frame-ancestors? ▼

It is largely redundant in current browsers, which prefer frame-ancestors when both are present. Many organisations still send both, because X-Frame-Options remains the header that legacy scanners, corporate proxies, and older embedded browsers understand. Sending both is harmless provided they agree; a DENY value alongside a permissive frame-ancestors list is a configuration conflict waiting to confuse an audit.

Can I set security headers with an HTML meta tag instead? ▼

Only partially. A Content-Security-Policy can be delivered via meta http-equiv, but the frame-ancestors, report-uri, and sandbox directives are ignored in that form, and the policy applies only after the parser reaches the tag. No other security header works as a meta tag at all. Send security headers from the server or the edge, where they cover every response including redirects and errors.

Regex Backtracking and ReDoS: Why Your Pattern Hangs and How to Fix It

Sun, 06 Sep 2026 00:00:00 +0000

Interactive Workbench LIVE

Regex Backtracking and ReDoS: Why Your Pattern Hangs and How to Fix It

Open Fullscreen ↗

Initializing Workbench...

100% Client-Side RAM Sandbox

🔒 Private Execution: Computations run in local browser memory. Zero server uploads. Zero server uploads.

Launch Fullscreen →

Free In-Browser Tool TOOLBOX UTILITY

RegEx Tester & Group Matcher

Toggle the g, i, m, s, and u flags live, inspect every capture group, and read a token-by-token explanation of what your pattern actually does.

Open RegEx Tester & Explainer →

Two Kinds of Regex Engine

Not all regex implementations share the same performance model, and the difference decides whether a pattern can be attacked.

	Backtracking (NFA)	Automaton (DFA/RE2)
Used by	JavaScript, Python `re`, Java, PCRE, .NET, Ruby	Go `regexp`, Rust `regex`, RE2, `grep -E`
Worst case	Exponential in input length	Linear in input length
Backreferences	Supported	Not supported
Lookaround	Supported	Not supported
Attackable	Yes	No

The trade is explicit: backtracking engines buy backreferences and lookaround at the cost of a worst-case time bound. JavaScript uses a backtracking engine, so every pattern you run against untrusted input carries a performance contract you need to understand.

How Backtracking Actually Fails

Take the pattern ^(a+)+$ and the input aaaa!.

The inner a+ is greedy, so it consumes all four a characters.
The outer + tries to repeat; there is nothing left, so it stops.
$ is checked. The next character is !, not end-of-string. Fail.
The engine backtracks: what if the inner a+ had taken three characters and the outer group repeated to take the fourth?
Fail again. What about 2 + 2? 2 + 1 + 1? 1 + 3? 1 + 1 + 2? 1 + 1 + 1 + 1?

Each of those is a distinct partition of the input, and every one must be tried before the engine can report no match. The number of ways to partition n items into ordered groups grows as 2^(n-1).

Input Length	Partitions Explored	Approximate Time
20	~524,000	milliseconds
25	~16.7 million	~0.1 seconds
30	~536 million	several seconds
35	~17 billion	minutes
40	~550 billion	hours

Add five characters, take thirty-two times longer. That is the entire mechanism behind ReDoS.

The critical precondition: the overall match must fail. A pattern that matches successfully finds its answer on the first greedy pass. This is why a vulnerable pattern looks perfectly fast in tests using valid inputs, and only detonates on malformed data — which is exactly what an attacker supplies.

The Three Vulnerable Shapes

Almost every real ReDoS reduces to one of three structures.

1. Nested Quantifiers

/^(a+)+$/ // quantifier inside a quantified group
/^(\d+)*$/
/^([a-z]+)+$/

The outer repetition and the inner repetition compete for the same characters. Ambiguity is the fuel.

2. Overlapping Alternation Under a Quantifier

/^(a|aa)+$/ // both branches match the letter a
/^(\w|\d)+$/ // \w already includes \d
/^(\s|\t|\n)*$/ // \s already includes \t and \n

If two branches can match the same text, the engine has two routes to every position, doubling the search space at each step.

3. Greedy Dot-Star Next to a Similar Pattern

/^(.*),(.*)$/ // both sides compete for every comma
/<div>(.*)<\/div>/ // .* happily crosses tag boundaries
/^(.*?)(.*?)(.*?)$/ // three lazy groups over one string

. matches almost everything, including the delimiter you are trying to find, so the engine must try every split point.

The Real-World Case

On 2 July 2019, Cloudflare’s global network returned HTTP 502 errors for roughly 30 minutes. The published post-mortem attributes the outage to a newly deployed WAF rule containing .*(?:.*=.*) — a nested greedy quantifier that consumed CPU across every machine in the fleet. One regular expression, global outage. The pattern shape above is not academic.

The Rewrites That Fix It

Replace nested quantifiers with a single one

/^(a+)+$/ // vulnerable
/^a+$/ // equivalent, linear

Ask what the outer quantifier adds. In the majority of vulnerable patterns, the answer is nothing.

Make alternation branches mutually exclusive

/^(a|aa)+$/ // vulnerable — branches overlap
/^a+$/ // same language, no ambiguity

/^(\w|\d)+$/ // vulnerable — \w contains \d
/^\w+$/ // same language

Swap greedy dots for negated character classes

/"(.*)"/ // dot crosses the closing quote and backtracks
/"([^"]*)"/ // cannot cross the delimiter at all — no ambiguity

This single substitution — [^delimiter]* instead of .* — is the highest-value change in practice. It also usually fixes the correctness bug where a greedy pattern swallowed two fields.

Emulate atomic groups with a lookahead

JavaScript has no atomic groups (?>...) and no possessive quantifiers a++. You can simulate them with a lookahead plus a backreference, which discards the inner group’s backtracking positions:

// Atomic equivalent of (?>\d+)
const atomic = /(?=(\d+))\1/;

The lookahead matches greedily, the backreference consumes exactly that text, and the engine cannot revisit the choice.

Bound the input before matching

const MAX = 512;

function safeTest(pattern, input) {
 if (typeof input !== 'string' || input.length > MAX) return false;
 return pattern.test(input);
}

Even an exponential pattern is harmless on 512 bytes. A length cap is a blunt instrument, but it is the one mitigation that works without understanding the pattern — apply it at every trust boundary.

Flags Worth Knowing

The tester exposes the five flags that matter most day to day:

Flag	Name	Effect	Gotcha
`g`	Global	Find all matches	Mutates `lastIndex` — see below
`i`	Ignore case	Case-insensitive matching	Unicode case folding needs `u`
`m`	Multiline	`^` and `$` match line boundaries	Does not change what `.` matches
`s`	DotAll	`.` also matches newlines	ES2018
`u`	Unicode	Pattern read as code points; enables `\p{...}`	Makes some previously legal escapes errors

ECMAScript also defines y (sticky), d (hasIndices, ES2022), and v (set notation, ES2024).

The `lastIndex` Trap

A regex literal with g carries mutable state. Reusing one across calls produces alternating results:

const re = /\d+/g;

re.test('123'); // true — lastIndex is now 3
re.test('123'); // false — resumes from index 3, finds nothing
re.test('123'); // true — lastIndex reset to 0 after the failure

Use a non-global regex for test, create the regex inside the function, or reset re.lastIndex = 0 before each use. The same hazard applies to exec in a loop — which is the intended use of g, but only when the loop consumes matches until null.

Detection and Tooling

Static analysis catches most real cases before deployment:

eslint-plugin-regexp with the no-super-linear-backtracking rule flags exponential and polynomial patterns in CI.
recheck performs both static and fuzzing-based analysis and reports an attack string.
Dependency advisories matter too: ReDoS reports against popular parsing and validation libraries are common, so keep npm audit in your pipeline.

Runtime containment for patterns you cannot rewrite — user-supplied search expressions, for instance:

Run matching in a worker thread you can terminate on a timeout. JavaScript regex evaluation is synchronous and uninterruptible on the main thread, so this is the only way to enforce a deadline.
Use a linear-time engine via bindings such as node-re2, accepting the loss of backreferences and lookaround.
Never compile a pattern supplied by a user without both of the above.

Step-by-Step: Diagnosing a Pattern with Toolbox

Open the tool: visit the .
Start from a preset or paste your own pattern into the pattern field.
Toggle the flags — g, i, m, s, u — and watch the match set change, which is the fastest way to confirm a flag is the actual cause of a bug.
Read the token explanation. The explainer breaks the pattern into tokens, which makes nested quantifiers and overlapping alternations visible rather than buried in punctuation.
Inspect capture groups against your sample text to verify indices and named groups resolve as expected.
Test the failure case, not the success case. Paste input that nearly matches — the right prefix with one wrong character at the end. Slow, vulnerable patterns only reveal themselves when the match fails.

Everything is evaluated by your browser’s own RegExp implementation, so test data never leaves the device — which matters when the sample text is a production log line or a customer record.

For the adjacent problem of validating structured text rather than free-form strings, is usually the better tool than a regular expression.

FAQ

Frequently Asked Questions

What is catastrophic backtracking? ▼

Catastrophic backtracking occurs when a backtracking regex engine must explore an exponential number of ways to divide the same input among nested quantifiers before it can conclude that no match exists. The pattern (a+)+$ against a long run of the letter a followed by an exclamation mark is the canonical example: each added character roughly doubles the work, so a string of 30 characters can take longer than a string of 29 by a full second.

What is a ReDoS attack? ▼

ReDoS, or Regular Expression Denial of Service, is an attack in which a request carries input crafted to trigger catastrophic backtracking in a server-side pattern. Because JavaScript regex evaluation is synchronous and blocks the event loop, a single such request can freeze an entire Node.js process. The Cloudflare global outage of 2 July 2019 was caused by exactly this class of bug in a WAF rule.

How do I know whether a pattern is vulnerable? ▼

Look for a quantifier applied to a group that already contains a quantifier or an alternation whose branches can match the same text, such as (a+)+, (\\s*,)*, or (.*)*. Then check whether the pattern can fail after that group, since backtracking only explodes on failure. Static analysers such as the ESLint no-super-linear-backtracking rule and the recheck library detect most real cases automatically.

Does adding an anchor fix a slow regex? ▼

Sometimes, but not reliably. Anchoring with a caret and dollar sign prevents the engine from retrying the pattern at every starting offset, which removes one polynomial factor. It does nothing about exponential blowup inside nested quantifiers, and a trailing dollar sign can make matters worse by guaranteeing the failure that triggers the full backtracking search. Restructuring the pattern is the real fix.

Should I validate email addresses with a regular expression? ▼

Not with a complex one. Full RFC 5322 address syntax is impractical to express as a maintainable pattern, and the elaborate email regexes circulating online are a frequent source of ReDoS. Use a minimal shape check such as one non-space run, an at sign, another non-space run containing a dot, then confirm the address by sending a verification message. Deliverability is the only real proof of validity.

URL Percent-Encoding Explained: RFC 3986, encodeURIComponent, and the %20 vs + Trap

Sun, 06 Sep 2026 00:00:00 +0000

Interactive Workbench LIVE

URL Percent-Encoding Explained: RFC 3986, encodeURIComponent, and the %20 vs + Trap

Open Fullscreen ↗

Initializing Workbench...

100% Client-Side RAM Sandbox

🔒 Private Execution: Computations run in local browser memory. Zero server uploads. Zero server uploads.

Launch Fullscreen →

Free In-Browser Tool TOOLBOX UTILITY

URL Percent Encoder & Decoder

Switch between Encode and Decode tabs, paste any string, and get instant UTF-8-correct percent-encoding with one-click copy.

Open URL Encoder & Decoder →

Why URLs Need Encoding at All

A URL is not free-form text. It is a structured identifier in which certain characters carry meaning: ? starts the query, & separates parameters, # begins the fragment, / divides path segments.

The moment user data containing those characters is dropped into a URL, the structure collapses:

https://example.com/search?q=fish & chips#1
 ^ ^ ^
 | | └── parsed as a fragment
 | └──────── parsed as a parameter separator
 └─────────────── raw space, invalid in a URL

The server sees the parameter q with value fish , a second empty parameter named chips, and a fragment of 1. Percent-encoding solves this by giving every problematic character an unambiguous escaped form.

https://example.com/search?q=fish%20%26%20chips%231

The RFC 3986 Character Classes

Everything follows from three sets defined in RFC 3986.

Unreserved — safe everywhere, never needs encoding

A-Z a-z 0-9 - . _ ~

Section 2.3 states these are equivalent whether escaped or not. Encoding them is legal but pointless, and normalisers will decode them back.

Reserved — structurally meaningful, must be encoded inside data

Group	Characters	Role
gen-delims	`:` `/` `?` `#` `[` `]` `@`	Separate the major URL components
sub-delims	`!` `$` `&` `'` `(` `)` `*` `+` `,` `;` `=`	Delimiters inside a component

Everything else — must be encoded

Spaces, control characters, ", <, >, \, ^, `, {, |, }, and every non-ASCII character.

The Percent-Encoding Rule

character -> UTF-8 bytes -> %HH for each byte

Character	UTF-8 Bytes	Encoded
space	`20`	`%20`
`&`	`26`	`%26`
`/`	`2F`	`%2F`
`%`	`25`	`%25`
`é`	`C3 A9`	`%C3%A9`
`€`	`E2 82 AC`	`%E2%82%AC`
`🚀`	`F0 9F 9A 80`	`%F0%9F%9A%80`

RFC 3986 §2.1 says the hexadecimal digits should be uppercase; normalisers uppercase them, and %2f and %2F are equivalent on decode.

The Three JavaScript Functions

Function	Leaves Unencoded	Verdict
`encodeURIComponent()`	`A-Z a-z 0-9 - _ . ! ~ * ' ( )`	Use this for values
`encodeURI()`	The above plus `; / ? : @ & = + $ , #`	Only for a whole URL
`escape()`	Legacy, emits non-standard `%uXXXX`	Never use — deprecated in Annex B

The Decision Rule

Encoding a piece of data? encodeURIComponent. Encoding an already-assembled URL? encodeURI.

const query = 'fish & chips';
const redirect = 'https://example.com/next?id=7';

// Correct — each value encoded independently.
const url =
 `https://example.com/search?q=${encodeURIComponent(query)}` +
 `&next=${encodeURIComponent(redirect)}`;

// Wrong — encodeURI leaves & and = intact, so the nested URL's
// own parameters merge into the outer query string.
const broken = encodeURI(`https://example.com/search?next=${redirect}`);

That second case — a URL nested inside a query parameter — is the classic failure. encodeURI preserves ? and & because it assumes they are your delimiters, and an OAuth redirect_uri or a ?next= parameter promptly falls apart.

Where `encodeURIComponent` Diverges from RFC 3986

encodeURIComponent leaves !, ', (, ), and * unescaped, although RFC 3986 classifies them as sub-delims rather than unreserved. Most servers cope, but strict parsers and signature-verifying APIs — AWS Signature V4 and OAuth 1.0a among them — do not. For strict compliance:

function rfc3986(str) {
 return encodeURIComponent(str).replace(
 /[!'()*]/g,
 (c) => '%' + c.charCodeAt(0).toString(16).toUpperCase()
 );
}

`%20` or `+`: Two Specifications, One Space

This trips up experienced engineers because both are correct — in different contexts.

Context	Space Becomes	Governing Specification
Path segment	`%20`	RFC 3986
Fragment	`%20`	RFC 3986
`encodeURIComponent()` output	`%20`	ECMA-262
HTML form `GET` submission	`+`	`application/x-www-form-urlencoded`
`URLSearchParams` serialisation	`+`	WHATWG URL Standard

const p = new URLSearchParams();
p.set('q', 'fish & chips');
p.toString(); // "q=fish+%26+chips"

encodeURIComponent('fish & chips'); // "fish%20%26%20chips"

Both round-trip correctly through a form-encoding parser. But a generic RFC 3986 parser reading a path decodes + as a literal plus sign. The practical consequences:

A + in a path segment is a plus, not a space. /files/my+file.txt refers to a file whose name contains a plus.
Encode a literal plus in form data as %2B. Otherwise user+tag@example.com arrives as user tag@example.com — the reason so many sites mangle plus-addressed email.
Pick one serialiser per codebase. Mixing URLSearchParams with hand-built strings produces query strings that decode inconsistently.

Failure Modes Worth Recognising

1. Double Encoding

Percent-encoding is not idempotent, because % is itself an encodable character.

"a b" -> encode -> "a%20b" -> encode again -> "a%2520b"

The server decodes once and hands your application the literal string a%20b. Symptom: values that visibly contain %20, %3D, or %26 after parsing. Cause: a value encoded at construction time and encoded again by a helper, a proxy, or a template. Encode exactly once, as late as possible.

2. Encoded Slashes Rejected by the Server

%2F inside a path segment is legal, but Apache HTTP Server defaults to AllowEncodedSlashes Off and returns 404 for such requests. Never place a value that might contain / into a path segment — put it in the query string instead.

3. `URIError: URI malformed`

decodeURIComponent throws on a truncated or invalid escape such as %E0%A4 or %ZZ. Any decode of untrusted input needs a guard:

function safeDecode(value) {
 try {
 return decodeURIComponent(value);
 } catch {
 return value; // Malformed input — return it untouched rather than crashing.
 }
}

4. Non-ASCII Hostnames Are Not Percent-Encoded

Percent-encoding applies to the path, query, and fragment. Internationalised domain names use Punycode (RFC 3492/5891) instead: münchen.de becomes xn--mnchen-3ya.de. Encoding a hostname with encodeURIComponent produces an unresolvable name.

5. Encoded Data in Logs Is Still Sensitive

Percent-encoding is not obfuscation. Anything placed in a query string lands in server access logs, proxy caches, Referer headers, and browser history. Tokens and secrets belong in headers or a request body — a point worth remembering when .

When to Reach for Base64 Instead

Percent-encoding is designed for text that is mostly URL-safe already. Encoding binary data with it is wasteful — every byte becomes three characters.

For binary payloads inside a URL, use base64url (RFC 4648 §5), which substitutes - and _ for + and / and drops padding, producing a string made entirely of unreserved characters. This is exactly what JWT segments use. The covers the mechanics, and the shows base64url in production.

Step-by-Step: Encoding with Toolbox

Open the tool: visit the .
Choose a tab — Encode to convert raw text into percent-encoded form, Decode to reverse it.
Paste the value, not the whole URL. Encode one query parameter value or one path segment at a time, then assemble the URL yourself.
Read the output — the encoder applies the browser’s native encodeURIComponent, so UTF-8 multi-byte characters convert correctly.
Copy the result and drop it into your request, config file, or test case.
Diagnose double encoding by pasting a suspect value into the Decode tab. If one pass still leaves % sequences behind, the value was encoded twice upstream.

Encoding runs entirely on your device through the browser’s own URL functions, so tokens, search terms, and customer identifiers in the strings you are debugging are never transmitted.

FAQ

Frequently Asked Questions

What is the difference between encodeURI and encodeURIComponent? ▼

encodeURI is for a complete URL and deliberately leaves the reserved structural characters ; / ? : @ & = + $ , # untouched so the URL keeps working. encodeURIComponent is for a single piece of data being placed inside a URL, such as one query parameter value, and escapes those reserved characters as well. Use encodeURIComponent for values and encodeURI only when handling an entire URL string.

Why does a space sometimes become %20 and sometimes a plus sign? ▼

Percent-encoding under RFC 3986 always represents a space as %20. The plus sign comes from a different and older specification, application/x-www-form-urlencoded, which HTML forms and the URLSearchParams API use for query strings. Both forms are decoded as a space by a form-encoding parser, but a generic RFC 3986 parser treats a literal plus as a plus, which is why the same string can decode differently on two servers.

Which characters never need to be percent-encoded? ▼

RFC 3986 section 2.3 defines the unreserved set as the ASCII letters A to Z and a to z, the digits 0 to 9, and the four symbols hyphen, period, underscore, and tilde. These characters are equivalent whether encoded or not, so encoding them adds length without changing meaning. Every other character is either reserved, meaning it has structural significance, or must be encoded.

Why did my URL break after being encoded twice? ▼

Percent-encoding is not idempotent. The percent sign is itself a character that must be encoded as %25, so running an already-encoded string through the encoder again turns %20 into %2520. The receiving server decodes only once and reads a literal %20 in the value. Encode exactly once, at the point where a raw value is inserted into a URL, and never on a string that already contains percent-escapes.

How are non-ASCII characters such as accented letters encoded? ▼

RFC 3986 section 2.5 specifies that a character is first converted to its UTF-8 byte sequence, then each byte is percent-encoded individually. The letter e-acute becomes the two bytes 0xC3 0xA9, which encode as %C3%A9. This is also why the legacy JavaScript escape function must never be used: it emits a non-standard %uXXXX form that is not valid percent-encoding.

How to Calculate IPv4 Subnets, Netmasks, and CIDR Blocks (Explained)

Fri, 04 Sep 2026 00:00:00 +0000

Free In-Browser Tool TOOLBOX UTILITY

IPv4 Subnet & CIDR Calculator

Interactive visual subnet calculator showing binary octets, IP ranges, bitmasks, and RFC 1918 classification.

Calculate Subnets with CIDR /24 →

What Is Subnetting & CIDR?

An IPv4 address is a 32-bit number typically written as four decimal octets separated by dots (e.g., 192.168.1.50).

Before Classless Inter-Domain Routing (CIDR) was standardized in RFC 4632, IPv4 addresses were split into rigid Class A, B, and C blocks, which caused immense IP waste. CIDR introduced variable-length subnet masking using slash notation (/N), where N (between 0 and 32) designates how many bits belong to the network prefix.

The Usable Host Calculation Formula

To calculate the number of assignable host addresses in any subnet:

$$\text{Host Bits } (H) = 32 - \text{CIDR Prefix}$$

$$\text{Total Addresses} = 2^H$$

$$\text{Usable Hosts} = 2^H - 2$$

Why Subtract 2?

Network Address (All host bits are 0): Identifies the subnet itself on routing tables.
Broadcast Address (All host bits are 1): Sends packets to all hosts on the subnet simultaneously.

CIDR Prefix Reference Table

CIDR Prefix	Subnet Mask	Total Addresses ($2^H$)	Usable Hosts ($2^H - 2$)	Typical Use Case
/30	`255.255.255.252`	4	2	Point-to-point router links
/29	`255.255.255.248`	8	6	Small cloud VPC subnets
/28	`255.255.255.240`	16	14	Small DMZ / firewall blocks
/26	`255.255.255.192`	64	62	Departmental LAN
/24	`255.255.255.0`	256	254	Standard home/office Wi-Fi
/23	`255.255.254.0`	512	510	Medium enterprise branch
/16	`255.255.0.0`	65,536	65,534	AWS / Azure Virtual Private Cloud
/8	`255.0.0.0`	16,777,216	16,777,214	Large ISP / National backbones

Binary Bitmasking: Finding Network and Broadcast IPs

Consider 10.0.15.35/20:

CIDR /20: 20 ones followed by 12 zeros.
Subnet Mask: 255.255.240.0.
Host Bits: $32 - 20 = 12 \implies 2^{12} = 4,096$ total IPs ($4,094$ usable hosts).
Network Address: Bitwise AND of 10.0.15.35 and 255.255.240.0 $\implies \mathbf{10.0.0.0}$.
Broadcast Address: Inverting the mask yields wildcard 0.0.15.255. Bitwise OR with Network IP $\implies \mathbf{10.0.15.255}$.
Usable Range: 10.0.0.1 to 10.0.15.254.

Eliminate manual subnet math errors with our .

Interactive Workbench LIVE

Calculate IPv4 Subnets, Netmasks, and CIDR Blocks (Explained)

Open Fullscreen ↗

Interactive visual subnet calculator showing binary octets, IP ranges, bitmasks, and RFC 1918 classification.

Initializing Workbench...

100% Client-Side RAM Sandbox

🔒 Private Execution: Computations run in local browser memory. Zero server uploads. Zero server uploads.

Launch Fullscreen →

FAQ

Frequently Asked Questions

Why do you subtract 2 when calculating usable hosts in a subnet? ▼

Every standard IPv4 subnet reserves the very first address as the Network Identifier and the very last address as the Subnet Broadcast Address. These two addresses cannot be assigned to individual network interfaces or host machines.

What is CIDR slash notation (e.g., /24)? ▼

Classless Inter-Domain Routing (CIDR) slash notation indicates how many leading bits of the 32-bit IPv4 address belong to the network prefix. For example, /24 means the first 24 bits are 1s (255.255.255.0), leaving 8 bits (2^8 = 256 addresses) for hosts.

What are the standard RFC 1918 private IPv4 ranges? ▼

The three private IP ranges reserved for local networks are: 10.0.0.0/8 (10.0.0.0 – 10.255.255.255), 172.16.0.0/12 (172.16.0.0 – 172.31.255.255), and 192.168.0.0/16 (192.168.0.0 – 192.168.255.255).

How to Format and Validate JSON in Your Browser (Safely)

Fri, 04 Sep 2026 00:00:00 +0000

Free In-Browser Tool TOOLBOX UTILITY

JSON Formatter & Validator

Format, validate, and inspect JSON payloads with line-numbered error diagnostics and zero server tracking.

Open JSON Formatter with Sample →

Why JSON Formatting & Validation Is Critical

JavaScript Object Notation (JSON) is the undisputed standard data interchange format across modern web APIs, microservices, database storage (PostgreSQL jsonb), and cloud configuration files.

However, minified API responses or hand-edited JSON files frequently cause catastrophic runtime crashes due to minute syntax infractions. When developers paste sensitive production payloads—such as authorization tokens, customer records, or API credentials—into random third-party formatting websites, they risk exposing confidential data to server logs, analytics trackers, and third-party scraping.

Using a 100% client-side JSON formatter guarantees that your data never leaves your workstation’s RAM.

Strict RFC 8259 Syntax Rules You Must Follow

JSON syntax is governed by the IETF RFC 8259 standard. Unlike JavaScript object literals, JSON enforces a rigid subset of rules:

Keys Must Be Double-Quoted: Single quotes ('id': 1) or unquoted keys (id: 1) will throw a syntax error. Only "id": 1 is valid.
Strings Must Use Double Quotes: Single quotes are strictly forbidden for string values.
No Trailing Commas: Trailing commas after the final element in an array [1, 2, 3,] or object {"a": 1,} violate the standard grammar.
Permitted Primitive Types Only:
- string (UTF-8, enclosed in double quotes)
- number (integer or floating point; NaN and Infinity are forbidden)
- boolean (true or false)
- null
- object ({ ... })
- array ([ ... ])
No Comments: Standard JSON does not support // single-line comments or /* */ block comments.

Common JSON Errors & How to Fix Them

Error Message	Root Cause	Solution
`Unexpected token ' in JSON at position X`	Using single quotes instead of double quotes	Replace all `'` with `"` around keys and strings
`Unexpected token , in JSON at position X`	Trailing comma after final key or array item	Remove the superfluous comma before `}` or `]`
`Unexpected token } in JSON at position X`	Missing value after colon or unclosed quotation	Ensure every key has a corresponding value
`Unterminated string in JSON at position X`	Unescaped line break or missing closing quote	Escape special characters (`\n`, `\t`, `\"`)

Architecture Comparison: Client-Side vs Server-Side Formatters

Security & Performance Dimension	In-Browser Client-Side (Toolbox)	Traditional Server-Side Tools
Data Transmission	0 KB (Never leaves browser RAM)	Transmitted via HTTP POST to third-party server
Server Logging Risk	Zero Risk (No server receives data)	High (Stored in Nginx/Apache access & error logs)
Execution Latency	Instantaneous (< 5ms via V8)	150ms – 800ms (Network round-trip latency)
Offline Availability	Fully functional offline	Fails without active internet connection
Compliance (GDPR / HIPAA)	100% Compliant	Potential compliance violation

Step-by-Step: Formatting JSON in Toolbox

Open the Tool: Navigate to the .
Paste Your Payload: Insert your raw or minified JSON payload into the input editor.
Instant Validation: The editor immediately executes JSON.parse(). If valid, it indents the structure with your choice of 2 spaces, 4 spaces, or tabs.
Debug Syntax Errors: If the payload contains errors, the diagnostic gutter highlights the exact line and column where parsing halted.
Copy or Minify: Click Copy Formatted to transfer the clean output to your clipboard, or click Minify to strip whitespace for production payloads.

Interactive Workbench LIVE

Format and Validate JSON in Your Browser (Safely)

Open Fullscreen ↗

Try formatting and validating your JSON payload in real time with line-numbered error diagnostics and zero server tracking.

Initializing Workbench...

100% Client-Side RAM Sandbox

🔒 Private Execution: Computations run in local browser memory. Zero server uploads. Zero server uploads.

Launch Fullscreen →

FAQ

Frequently Asked Questions

Is it safe to format sensitive JSON in an online tool? ▼

Yes, provided the tool runs strictly client-side. Client-side tools execute parsing inside your browser's local JavaScript V8 engine without sending any HTTP network requests to external servers. Always check the Network tab to confirm zero outgoing payloads.

Why does JSON.parse() reject trailing commas? ▼

The RFC 8259 specification explicitly defines arrays and objects as separated by commas, with no trailing comma allowed after the final value. Parsers adhere strictly to this grammar to ensure cross-language interoperability.

How can I fix invalid JSON with unquoted keys or single quotes? ▼

Standard JSON strictly mandates double quotes around all keys and string values. You can use an in-browser formatter that automatically replaces single quotes and wraps unquoted identifiers in double quotes before validating.

JWT Security 101: How to Decode, Inspect, and Verify Claims Client-Side

Fri, 04 Sep 2026 00:00:00 +0000

Free In-Browser Tool TOOLBOX UTILITY

JWT Token Inspector & Decoder

Analyze JWT expiration, token issuance, audience, and signature algorithms locally with real-time expiration count-downs.

Inspect JWT Token Safely →

What Is a JSON Web Token (JWT)?

Defined by RFC 7519, a JSON Web Token is an open, compact, URL-safe container for transferring claims between two parties. JWTs are the dominant authentication mechanism in modern single-page applications (SPAs), microservice architectures, and OAuth 2.0 / OpenID Connect (OIDC) workflows.

A JWT consists of three distinct parts separated by dots (.):

Header.Payload.Signature

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyLCJleHAiOjE3MDAwMDAwMDB9.4pz-KE...

The Three Components of a JWT

1. The Header

The header describes the cryptographic metadata and token type:

{
 "alg": "HS256",
 "typ": "JWT"
}

alg: The cryptographic signing algorithm (e.g., HS256, RS256, ES256).
typ: Token type, typically "JWT".

2. The Payload (Claims)

The payload contains statements about an entity (usually the authenticated user) and additional session metadata.

Standard Registered Claims:

iss (Issuer): Identifies the authority that issued the JWT.
sub (Subject): Identifies the principal subject of the token (e.g., user ID).
aud (Audience): Identifies the intended recipients or resource servers.
exp (Expiration Time): Unix epoch timestamp after which the token must not be accepted.
nbf (Not Before): Identifies the timestamp before which the token is invalid.
iat (Issued At): Timestamp recording when the token was generated.

3. The Signature

The signature validates that the token was neither tampered with nor forged in transit. For HMAC-SHA256:

HMACSHA256(
 base64UrlEncode(header) + "." + base64UrlEncode(payload),
 secret
)

Critical JWT Security Pitfalls

1. The “None” Algorithm Attack

In early implementations of RFC 7519, servers supported unsigned tokens where "alg": "none". Attackers bypassed authentication by altering the payload to grant admin privileges and setting "alg": "none" with an empty signature. Modern verification libraries strictly whitelist approved algorithms (algorithms: ['RS256']).

2. Key Confusion (Asymmetric to Symmetric)

When an API verifies tokens using an asymmetric algorithm (like RS256), the server uses a public key to verify and a private key to sign. In key confusion attacks, an adversary changes the header to "alg": "HS256" and signs the token using the server’s publicly accessible public key as the HMAC secret! Vulnerable servers verifying with jwt.verify(token, key) mistakenly treat the public key string as a shared symmetric secret.

3. Leaking Production Secrets to Web Tools

Never paste live customer session tokens or sensitive API tokens into third-party servers. Using our ensures parsing executes purely in local browser memory.

Interactive Workbench LIVE

JWT Security 101: How to Decode, Inspect, and Verify Claims Client-Side

Open Fullscreen ↗

Decode and inspect JWT headers, standard claims, and expiration timestamps securely in your browser.

Initializing Workbench...

100% Client-Side RAM Sandbox

🔒 Private Execution: Computations run in local browser memory. Zero server uploads. Zero server uploads.

Launch Fullscreen →

FAQ

Frequently Asked Questions

Is a JWT token encrypted? ▼

No. Standard JWTs (RFC 7519) are signed, not encrypted. The header and payload are simply Base64Url-encoded JSON strings. Anyone with access to the token string can decode and read the underlying claims in plaintext.

Why is it dangerous to paste production JWTs into random online debuggers? ▼

Many online token inspectors transmit tokens over HTTP to their backend servers for logging or telemetry. If your token contains confidential user IDs, role permissions, or OAuth access scopes, server-side log ingestion creates severe security liabilities. Always use client-side tools.

What is the 'algorithm none' vulnerability in JWT verification? ▼

The 'none' algorithm is an optional spec in RFC 7519 for unsigned tokens. If an insecure server verification library accepts alg: 'none', an attacker can strip the signature, modify the payload (e.g. set 'admin': true), and forge unauthorized authentication.

Understanding UUID v4 vs v7: Generation, Differences, and Database Indexing

Fri, 04 Sep 2026 00:00:00 +0000

Free In-Browser Tool TOOLBOX UTILITY

UUID & GUID Generator

Generate cryptographically random UUID v4 or time-ordered UUID v7 with custom casing, batch generation, and zero server logging.

Generate UUID v7 Instantly →

What Is a UUID?

A Universally Unique Identifier (UUID), standardized by RFC 4122 and recently modernized by RFC 9562, is a 128-bit value formatted as 32 hexadecimal digits separated by hyphens in an 8-4-4-4-12 pattern:

xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx

M represents the UUID version (e.g., 4 for random, 7 for Unix epoch time-sorted).
N represents the variant (typically 8, 9, a, or b, encoding the 10xx binary variant).

The Hidden Penalty of UUID v4 in Databases

For over two decades, UUID v4 has been the default choice for distributed systems because it requires no central coordination:

f47ac10b-58cc-4372-a567-0e02b2c3d479 (v4: 122 random bits)

However, when used as a primary key in relational databases (such as PostgreSQL, MySQL InnoDB, or SQL Server), UUID v4 causes severe performance degradation as tables scale beyond millions of rows:

B-Tree Index Fragmentation: B-Tree indexes require sorted keys. Because UUID v4 values are completely random, new inserts land in arbitrary locations throughout the index tree.
Page Splits & Write Amplification: When an index page fills up, the database engine is forced to split the page into two, rewriting existing data to disk.
Buffer Pool Cache Eviction: Because incoming writes touch random pages across the entire index, the database cannot keep the “hot” working set in memory, leading to heavy random SSD I/O.

Enter UUID v7: Time-Sorted Distributed Identifiers

Published in RFC 9562, UUID v7 directly eliminates index fragmentation while preserving decentralized generation:

 0 1 2 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unix_ts_ms |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unix_ts_ms | ver | rand_a |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|var| rand_b |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rand_b |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

UUID v7 Bit Anatomy:

Bits 0–47 (48 bits): Big-endian unsigned 48-bit integer recording the Unix timestamp in milliseconds.
Bits 48–51 (4 bits): Version nibble set to 0111 (0x7).
Bits 52–63 (12 bits): Sub-millisecond sequence or pseudo-random bits (rand_a).
Bits 64–65 (2 bits): RFC variant bits set to 10.
Bits 66–127 (62 bits): Cryptographically secure random entropy (rand_b).

Because the leading 48 bits track real-world time, UUID v7 values sort sequentially by creation time. In B-Tree indexes, new inserts append directly to the rightmost leaf page, reducing page splits to nearly zero.

Feature & Performance Comparison

Attribute	Auto-Increment `BIGINT`	UUID v4 (Random)	UUID v7 (Time-Ordered)
Standard Spec	Database Engine Native	RFC 4122	RFC 9562
Bit Length	64 bits	128 bits	128 bits
Decentralized Generation	❌ (Requires centralized DB lock)	✅ (Fully decentralized)	✅ (Fully decentralized)
B-Tree Index Locality	✅ Optimal sequential appends	❌ Severe random page splits	✅ Optimal sequential appends
Information Leakage	⚠️ High (Reveals order/volume)	✅ Zero	⚠️ Leaks millisecond timestamp
Distributed Collisions	Single point of failure	$1 \text{ in } 2^{122}$	$1 \text{ in } 2^{74} \text{ per millisecond}$

How to Generate UUIDs Client-Side in Your Browser

In modern browsers, generating cryptographically secure identifiers relies on the Web Cryptography API (crypto.getRandomValues):

// Native Web Crypto UUID v4
const uuidV4 = crypto.randomUUID();
console.log(uuidV4); // e.g. 3b241101-e2bb-4255-8caf-4136c566a962

For UUID v7, client-side tools pack the current Date.now() timestamp into the top 48 bits, set the 0x7 version bits, and populate the remaining 74 bits with cryptographically secure random bytes from crypto.getRandomValues(new Uint8Array(10)).

Try generating batch UUIDs with our .

Interactive Workbench LIVE

UUID v4 vs v7: Generation, Differences, and Database Indexing

Open Fullscreen ↗

Generate cryptographically secure, time-sortable UUID v7 and random UUID v4 identifiers directly in your browser.

Initializing Workbench...

100% Client-Side RAM Sandbox

🔒 Private Execution: Computations run in local browser memory. Zero server uploads. Zero server uploads.

Launch Fullscreen →

FAQ

Frequently Asked Questions

Why is UUID v7 better than UUID v4 for database primary keys? ▼

UUID v7 starts with a 48-bit Unix millisecond timestamp, making newly generated IDs monotonically increasing. When inserted into B-Tree database indexes (PostgreSQL, MySQL), new records append sequentially to the leaf nodes rather than causing random page splits and disk cache churn.

Are UUID v7 identifiers cryptographically secure? ▼

Yes. UUID v7 combines a 48-bit timestamp with 74 bits of cryptographically secure random entropy. With 74 bits of entropy per millisecond, the probability of a collision in distributed environments is negligible.

Is UUID v7 backwards-compatible with standard 36-character UUID parsers? ▼

Yes. UUID v7 adheres strictly to the canonical 8-4-4-4-12 string layout specified in RFC 9562, featuring the standard version nibble (7) and variant bits (10xx). Any standard UUID parser can read, validate, and store it.

Developer-Tools | Toolbox Guides & Articles

HTTP Security Headers: A Practical Hardening Guide for CSP, HSTS, and Cross-Origin Isolation

HTTP Security Headers: A Practical Hardening Guide for CSP, HSTS, and Cross-Origin Isolation

HTTP Header Security Auditor

Headers Are the Cheapest Security You Will Ever Deploy

Content-Security-Policy: The One That Does the Work

The Modern Strict Policy

Roll It Out in Report-Only Mode First

Directives That Do Not Behave as Expected

Strict-Transport-Security

Clickjacking, Sniffing, and Referrer Leakage

X-Content-Type-Options: nosniff

X-Frame-Options

Referrer-Policy

Permissions-Policy

Cross-Origin Isolation: COOP, COEP, CORP

Headers to Delete

Server Configuration Pitfalls

Nginx: inheritance and error responses

Apache

A Note on CORS

Step-by-Step: Auditing with Toolbox

Frequently Asked Questions

Regex Backtracking and ReDoS: Why Your Pattern Hangs and How to Fix It

Regex Backtracking and ReDoS: Why Your Pattern Hangs and How to Fix It

RegEx Tester & Group Matcher

Two Kinds of Regex Engine

How Backtracking Actually Fails

The Three Vulnerable Shapes

1. Nested Quantifiers

2. Overlapping Alternation Under a Quantifier

3. Greedy Dot-Star Next to a Similar Pattern

The Real-World Case

The Rewrites That Fix It

Replace nested quantifiers with a single one

Make alternation branches mutually exclusive

Swap greedy dots for negated character classes

Emulate atomic groups with a lookahead

Bound the input before matching

Flags Worth Knowing

The lastIndex Trap

Detection and Tooling

Step-by-Step: Diagnosing a Pattern with Toolbox

Frequently Asked Questions

URL Percent-Encoding Explained: RFC 3986, encodeURIComponent, and the %20 vs + Trap

URL Percent-Encoding Explained: RFC 3986, encodeURIComponent, and the %20 vs + Trap

URL Percent Encoder & Decoder

Why URLs Need Encoding at All

The RFC 3986 Character Classes

Unreserved — safe everywhere, never needs encoding

Reserved — structurally meaningful, must be encoded inside data

Everything else — must be encoded

The Percent-Encoding Rule

The Three JavaScript Functions

The Decision Rule

Where encodeURIComponent Diverges from RFC 3986

%20 or +: Two Specifications, One Space

Failure Modes Worth Recognising

1. Double Encoding

2. Encoded Slashes Rejected by the Server

3. URIError: URI malformed

4. Non-ASCII Hostnames Are Not Percent-Encoded

5. Encoded Data in Logs Is Still Sensitive

When to Reach for Base64 Instead

Step-by-Step: Encoding with Toolbox

Frequently Asked Questions

How to Calculate IPv4 Subnets, Netmasks, and CIDR Blocks (Explained)

IPv4 Subnet & CIDR Calculator

What Is Subnetting & CIDR?

The Usable Host Calculation Formula

Why Subtract 2?

CIDR Prefix Reference Table

Binary Bitmasking: Finding Network and Broadcast IPs

Calculate IPv4 Subnets, Netmasks, and CIDR Blocks (Explained)

Frequently Asked Questions

How to Format and Validate JSON in Your Browser (Safely)

JSON Formatter & Validator

Why JSON Formatting & Validation Is Critical

Strict RFC 8259 Syntax Rules You Must Follow

Common JSON Errors & How to Fix Them

`X-Content-Type-Options: nosniff`

`X-Frame-Options`

`Referrer-Policy`

`Permissions-Policy`

The `lastIndex` Trap

Where `encodeURIComponent` Diverges from RFC 3986

`%20` or `+`: Two Specifications, One Space

3. `URIError: URI malformed`