DEV Community: Avinash Kori

How I Run a Real C Compiler in the Browser with WebAssembly

Avinash Kori — Sat, 17 Oct 2026 10:57:11 +0000

Most online compilers send your code to a server, run it in a container and send the output back. I wanted one where the code never leaves the browser. Here is how the C compiler on Devtoolry works, and what surprised me along the way.

The pieces

Clang and LLD compiled to WebAssembly. I use the YoWASP build of Clang 21. It is a normal npm package served from jsDelivr, about 23 MB compressed. The browser caches it after the first run.
A module Web Worker. Compiling and running happen off the main thread, so the page stays responsive and an infinite loop can't freeze the tab.
Compile to wasm32-wasi in memory. The worker runs clang -std=c17 -O2 -Wall main.c -lm against an in-memory file system and gets a main.wasm binary back.
A minimal WASI host. The program needs stdin, stdout, stderr, clocks and randomness. It gets no file system and no network, which makes the sandbox simple.
A timeout that kills the worker. The page starts a timer when the program starts running (compilation and the first download don't count). If it fires, the page calls worker.terminate() and shows "Timed out". Terminating a worker is the only reliable way to stop a tight for (;;) loop.

The core of the run step is short:

const program = await WebAssembly.compile(binary);
const wasi = createWasi({ args: ['main'], stdin, write: (fd, text) => emit(fd === 2 ? 'stderr' : 'stdout', text) });
const instance = await WebAssembly.instantiate(program, wasi.imports);
postMessage({ type: 'status', status: 'ready' }); // the page starts the time limit here
const exitCode = wasi.start(instance);

What behaves differently from native C

Testing with a lot of real beginner programs turned up some differences worth knowing:

32-bit sizes. wasm32 means sizeof(long) == 4 and sizeof(void *) == 4.
NULL reads don't crash. Address 0 is valid linear memory, so reading through a NULL pointer returns a value (0 in my tests) instead of a segfault. Out-of-bounds access past the end of memory does trap.
No fortified libc. A strcpy overflow that aborts on Ubuntu GCC silently corrupts memory here. Clang still warns at compile time ("'strcpy' will always overflow").
No interactive stdin. Input has to be typed into a box before running, because WASI's stdin is a byte buffer here, not a terminal.
Turbo C headers. conio.h doesn't exist, and gets() is rejected because C11 removed it. These are the two most common reasons beginner code fails.

Making C++ fast enough

C++ was the slow one: parsing <iostream>, <vector> and friends took 5–9 seconds per compile in WebAssembly. A precompiled header of the common standard headers, built once with the exact same Clang version and downloaded in the background, cuts a typical compile to 1–3 seconds. As a bonus, the header list doubles as GCC's <bits/stdc++.h>, which competitive programmers expect.

Was it worth it?

For learning and quick tests, yes. There's no account and no queue, it works on a phone, and privacy comes for free. The trade-offs are the first download and the lack of threads, files and sockets.

If you want to dig into the C side, I wrote up pointers, strings and GCC vs Clang with output from both compilers. Questions about the worker or the WASI shim are welcome in the comments.

How to Preview HTML Code Online Safely: Sandboxed iframes Explained

Avinash Kori — Sat, 17 Oct 2026 10:32:04 +0000

Previewing HTML sounds trivial: put the markup in a page and let the browser draw it. It stops being trivial as soon as the HTML comes from somewhere you don't fully trust, such as an email template from a vendor, a snippet from a forum, a file a user uploaded or output from a language model. HTML can carry scripts, forms and links that act with the permissions of whatever page displays it.

This article explains how to look at any HTML safely: the <iframe sandbox> attribute, inline documents with srcdoc, how the Content Security Policy adds a second wall, and why previews sometimes look broken. The same techniques power the HTML Viewer on this site, which you can use to try every example below.

Why rendering HTML can be dangerous

When a page inserts HTML into itself, for example with element.innerHTML = untrusted, that HTML becomes part of the page. Any script it manages to run can read the page's cookies (unless they are HttpOnly), its local storage and everything the user sees, and can send requests as the signed-in user. This is cross-site scripting (XSS), one of the most common web vulnerabilities.

Scripts don't need a <script> tag. Event handler attributes run code too:

<img src="does-not-exist.png" onerror="alert('this runs')">

The image fails to load, the onerror handler fires, and the code runs. Filtering out <script> tags with a regular expression doesn't make HTML safe; there are far too many ways to run code. There are two reliable approaches: sanitise the HTML with a proven library such as DOMPurify, or render it somewhere it cannot reach your page. For a preview, the second approach is simpler and keeps the markup exactly as written.

The sandboxed iframe

An <iframe> displays a separate document inside a rectangle on the page. The sandbox attribute puts that document under strict restrictions. With an empty value, everything is switched off:

<iframe sandbox srcdoc="<h1>Hello</h1><p>Rendered safely.</p>"></iframe>

In a sandboxed frame with no permissions:

scripts don't run, including onerror and other event handlers;
forms can't be submitted;
pop-ups, new windows and modal dialogs are blocked;
the frame can't navigate the page around it;
the content gets a unique, opaque origin, so it can't read the parent page's cookies, storage or DOM, even though it was created by that page.

You switch individual capabilities back on by listing them: sandbox="allow-scripts", sandbox="allow-forms allow-popups" and so on. The rule is to grant as little as possible.

srcdoc holds the HTML of the framed document directly, so nothing has to be uploaded or served from a URL. That is how an online HTML viewer can render your code entirely in the browser.

The one combination to avoid

Two permissions are dangerous together: allow-scripts and allow-same-origin. With both, a framed document that is same-origin with its parent (and a srcdoc document is) can run a script that reaches into the parent page and removes the sandbox attribute from its own iframe. At that point the sandbox does nothing.

So a safe preview that needs JavaScript uses sandbox="allow-scripts" without allow-same-origin. The scripts run, but in an opaque origin with no access to your page. That is exactly what the HTML Viewer does when you switch on "Run scripts": it adds allow-scripts (and allow-modals, so alert() works) and nothing else.

A second wall: Content Security Policy

A sandbox limits what the framed document can do to its parent. A Content Security Policy (CSP) limits what any document on the site can load and run. An srcdoc iframe inherits the CSP of the page that creates it, so if the site only allows scripts from its own origin, a preview can't load a script from a random CDN either, even with scripts enabled.

This is why a pasted snippet with <script src="https://example.com/library.js"> may not work in a preview while inline <script> blocks do. It is a deliberate trade-off: the preview shows your markup and inline code, but it can't be used to pull in arbitrary third-party code.

Why your preview looks broken

Most "the preview is wrong" problems have one of these causes:

Relative URLs. src="images/logo.png" or href="style.css" are resolved against a base URL, and an inline document has no folder to resolve them against. Use absolute https:// URLs, or add a <base href="https://your-site.example/"> tag inside the snippet.
Missing styles. The framed document is isolated, so it doesn't inherit the CSS of the page around it. Add a <style> block or link a public stylesheet.
Scripts switched off. Content generated by JavaScript (frameworks, charts, sliders) stays empty until scripts are allowed.
Forms do nothing. Submitting is blocked in the sandbox, which is what you want for untrusted markup.
Server-side templates. PHP, Razor (.cshtml), JSX or Jinja code is executed on a server before a browser ever sees it. Paste the HTML the server produces, not the template, or the directives appear as plain text.

Hard-to-read markup is another common complaint. Run minified or machine-generated HTML through the HTML Formatter first, and the structure becomes obvious.

Previewing HTML emails

HTML emails are a common reason to need a quick preview. A viewer shows how a browser renders the markup, which is a good first check of the layout, images and links. Email clients are stricter than browsers, though: some ignore <style> blocks, most block scripts entirely, and many need tables for layout and inline style attributes. Treat a browser preview as a draft check, and test the final email in the real clients your readers use.

The same goes for meta tags and social cards: a viewer renders the visible page, while tags in the <head> only matter to search engines and social networks. Our guide to HTML meta tags for SEO explains which ones count.

How to see the HTML of any web page

To inspect how an existing page is built, open its source in the browser with Ctrl+U (Cmd+Option+U in Chrome on a Mac), or put view-source: in front of the address. You can copy parts of that source into a viewer to render them in isolation, for example to debug a single card or table.

Keep in mind that the source is the HTML the server sent. Pages built by JavaScript frameworks may contain little more than an empty <div id="root">; the browser's developer tools (F12, Elements tab) show the live document after scripts have run.

Summary

Never insert untrusted HTML directly into a page: event handlers like onerror run code even without <script> tags.
Render previews in an <iframe sandbox> with srcdoc. An empty sandbox blocks scripts, forms, pop-ups and access to the parent page.
If scripts are needed, use allow-scripts alone. Never combine it with allow-same-origin.
A CSP adds a second layer by controlling what any document can load.
Broken previews usually come down to relative URLs, missing styles or disabled scripts.

Paste your markup into the HTML Viewer to see it rendered safely as you type. When it looks right, the HTML to PDF converter turns the same HTML into a document, and the HTML Entity Encoder escapes code samples you want to show as text rather than render.

Originally published on Devtoolry.

Pointers in C Explained: Addresses, Arrays and Memory with Runnable Examples

Avinash Kori — Sat, 17 Oct 2026 10:31:31 +0000

Pointers are the part of C that decides whether the language feels simple or impossible. The rules are small: a pointer is a variable that stores an address, & takes an address and * follows one. The difficulty comes from what those rules make possible: functions that change their arguments, arrays that turn into pointers, memory you allocate and must free yourself.

This guide builds that up one step at a time. Every program below was compiled and run with Clang 21 in the online C Compiler and with GCC 11, and the output shown is the real output. Paste any of them into the compiler, change a line and run it again: that is the fastest way to make pointers click.

What a pointer is

Every variable lives somewhere in memory, and that location has an address. A pointer is a variable whose value is such an address.

#include <stdio.h>

int main(void) {
    int score = 42;
    int *p = &score;

    printf("score = %d\n", score);
    printf("*p    = %d\n", *p);
    printf("p == &score: %s\n", p == &score ? "yes" : "no");

    *p = 99;
    printf("score after *p = 99: %d\n", score);
    return 0;
}

score = 42
*p    = 42
p == &score: yes
score after *p = 99: 99

Read the declarations out loud and they make sense:

int *p declares p as a "pointer to int".
&score is "the address of score".
*p is "the int that p points to". Reading it gives 42; assigning to it changes score, because *p and score are the same memory.

The * has two jobs, which is the first source of confusion. In a declaration (int *p) it says "this is a pointer". In an expression (*p = 99) it means "follow the pointer". The two uses are related but not the same thing.

You can print an address with printf("%p\n", (void *)p), but the number changes from run to run and machine to machine, so it is rarely useful except to see that two pointers are equal.

Why functions need pointers

C passes every argument by value: the function receives a copy. That is why this classic swap does nothing:

#include <stdio.h>

void swap_wrong(int a, int b) {
    int tmp = a; a = b; b = tmp;
}

void swap(int *a, int *b) {
    int tmp = *a; *a = *b; *b = tmp;
}

int main(void) {
    int x = 1, y = 2;
    swap_wrong(x, y);
    printf("after swap_wrong: x=%d y=%d\n", x, y);
    swap(&x, &y);
    printf("after swap:       x=%d y=%d\n", x, y);
    return 0;
}

after swap_wrong: x=1 y=2
after swap:       x=2 y=1

swap_wrong swaps its own copies, which disappear when it returns. swap receives the addresses of x and y, so *a and *b are the caller's variables. This is also why scanf("%d", &n) needs the &: scanf has to write into your variable, so it needs its address. Our guide to reading input in C and C++ covers the scanf side in detail.

Pointers and arrays

An array name used in an expression turns ("decays") into a pointer to its first element. That is why indexing and pointer arithmetic are interchangeable:

#include <stdio.h>

void show_size(int arr[]) {
    printf("inside function: sizeof arr = %zu\n", sizeof arr);
}

int main(void) {
    int nums[5] = {10, 20, 30, 40, 50};
    int *p = nums;

    printf("nums[2] = %d, *(nums + 2) = %d, p[2] = %d\n", nums[2], *(nums + 2), p[2]);
    printf("in main: sizeof nums = %zu\n", sizeof nums);
    show_size(nums);
    return 0;
}

nums[2] = 30, *(nums + 2) = 30, p[2] = 30
in main: sizeof nums = 20
inside function: sizeof arr = 4

nums[2] is defined as *(nums + 2), so all three expressions read the same element. The surprise is the last line. In main, nums is a real array of five 4-byte ints, 20 bytes. In show_size, the parameter int arr[] is really int *arr, so sizeof gives the size of a pointer: 4 bytes in the WebAssembly build of the online compiler, 8 bytes with GCC on a 64-bit PC. Both compilers warn about it (-Wsizeof-array-argument).

The practical rule: a function never knows the length of an array you pass it. Pass the length as a separate argument, as every standard function from qsort to fgets does.

Pointer arithmetic

Adding 1 to a pointer moves it to the next element, not the next byte. The compiler scales by the size of the type:

#include <stdio.h>

int main(void) {
    double prices[3] = {9.5, 12.25, 3.75};
    double *first = &prices[0];
    double *last = &prices[2];

    printf("elements between: %td\n", last - first);
    printf("bytes between:    %td\n", (char *)last - (char *)first);

    double total = 0;
    for (double *p = prices; p < prices + 3; p++) total += *p;
    printf("total: %.2f\n", total);
    return 0;
}

elements between: 2
bytes between:    16
total: 25.50

Subtracting two pointers into the same array gives the number of elements between them (type ptrdiff_t, printed with %td). Casting to char * shows the bytes: two doubles of 8 bytes each. The loop walks the array with a pointer instead of an index, a style you will see often in older C code. Pointing one past the last element (prices + 3) is allowed as a loop end; reading through it is not.

Allocating memory with malloc and free

Arrays declared inside a function vanish when it returns. When the size is known only at run time, or the data must outlive the function, allocate it on the heap:

#include <stdio.h>
#include <stdlib.h>

int *make_squares(int n) {
    int *a = malloc(n * sizeof *a);
    if (a == NULL) return NULL;
    for (int i = 0; i < n; i++) a[i] = i * i;
    return a;
}

int main(void) {
    int n = 6;
    int *sq = make_squares(n);
    if (sq == NULL) {
        printf("out of memory\n");
        return 1;
    }
    for (int i = 0; i < n; i++) printf("%d ", sq[i]);
    printf("\n");
    free(sq);
    sq = NULL;
    return 0;
}

0 1 4 9 16 25

Three habits make heap code safe. Write n * sizeof *a rather than n * sizeof(int), so the size stays right if the type changes. Check for NULL, because malloc can fail. And call free exactly once for every successful malloc, then set the pointer to NULL so an accidental second free or later use is easy to spot.

Pointers to pointers

A function that must change which address the caller's pointer holds needs a pointer to that pointer, char **:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int duplicate(const char *src, char **out) {
    char *copy = malloc(strlen(src) + 1);
    if (copy == NULL) return -1;
    strcpy(copy, src);
    *out = copy;
    return 0;
}

int main(void) {
    char *name = NULL;
    if (duplicate("devtoolry", &name) == 0) {
        printf("copy: %s (%zu chars)\n", name, strlen(name));
        free(name);
    }
    return 0;
}

copy: devtoolry (9 chars)

It is the same idea as swap: to change an int you pass an int *; to change a char * you pass a char **. The + 1 in the malloc call makes room for the string's terminating '\0', which strlen does not count.

const and pointers

const can protect the data, the pointer, or both, depending on where it goes:

int main(void) {
    int a = 1, b = 2;
    const int *p = &a;
    int *const q = &a;
    *p = 5;
    q = &b;
    return 0;
}

main.c:5:8: error: read-only variable is not assignable
    5 |     *p = 5;
      |     ~~ ^
main.c:6:7: error: cannot assign to variable 'q' with const-qualified type 'int *const'
    6 |     q = &b;
      |     ~ ^

Read the declaration from right to left. const int *p is "a pointer to a constant int": you can move p, but not change the int through it. int *const q is "a constant pointer to an int": you can change the int, but q always points to a. Function parameters such as const char *src in duplicate above promise the caller that the function will not modify their data.

The bugs pointers cause

Most pointer bugs fall into a few groups:

Uninitialised pointers. int *p; *p = 1; writes to a random address. Initialise every pointer, to NULL if nothing else.
Dangling pointers. Returning the address of a local variable, or using memory after free. The program may appear to work, and different compilers behave differently: for int *broken(void) { int local = 7; return &local; }, GCC at -O2 returns NULL while Clang returns the stale address. Both warn, so never ignore that warning.
Off-by-one access. Reading a[n] in an array of n elements. C does not check bounds.
Memory leaks. Losing the only pointer to allocated memory before freeing it.
Double free. Calling free twice on the same pointer.

Compiler warnings catch a surprising number of these. Always compile with -Wall (the online compiler does), read every warning, and when a program crashes, look at the compiler errors guide and the line numbers the compiler gives you. Printing values and addresses step by step is still the most effective debugging tool for pointer code.

Summary

A pointer stores an address. &x gets the address of x; *p reads or writes the value at that address.
C passes arguments by value, so functions that change the caller's variables take pointers.
Arrays decay to pointers. a[i] is *(a + i), and a function cannot know an array's length unless you pass it.
Pointer arithmetic counts elements, not bytes.
Every malloc needs a NULL check and exactly one free.
Read const declarations right to left.

Try changing the examples in the C Compiler: remove an &, pass the wrong length, free twice, and read what the compiler and the program say. If you prefer containers to raw pointers, the same programs can be rewritten with std::vector in the C++ Compiler, and the Number Base Converter helps when you print addresses or bit patterns in hex.

Originally published on Devtoolry.

JWT Explained: Structure, Claims and How to Verify a Token

Avinash Kori — Thu, 15 Oct 2026 15:18:53 +0000

JSON Web Tokens (JWTs) are everywhere in modern authentication: OAuth and OpenID Connect use them, single-page apps send them in Authorization headers, and microservices pass them to each other. They are also widely misunderstood. A JWT is not encrypted, decoding one is not the same as verifying it, and a few common shortcuts turn them into a security hole.

This guide takes a real token apart, explains every piece, and lists the checks your server must make before trusting one.

A real token, taken apart

Here is a complete JWT, signed with HS256 and the secret correct-horse-battery-staple:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyXzEyMyIsIm5hbWUiOiJBZGEgTG92ZWxhY2UiLCJyb2xlIjoiYWRtaW4iLCJpYXQiOjE3OTIwNTEyMDAsImV4cCI6MTc5MjA1NDgwMH0.mEEzS78g7k66oYCyIa17SFw9_XR6J_6u5wH_eyT1qI0

It looks like random text, but it's three parts separated by dots: header, payload and signature. The first two are just JSON encoded with Base64URL (Base64 with - and _ instead of + and /, and no = padding). Decode them and you get:

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

{
  "sub": "user_123",
  "name": "Ada Lovelace",
  "role": "admin",
  "iat": 1792051200,
  "exp": 1792054800
}

Paste the token into the JWT Decoder to see the same thing, with the timestamps converted to readable dates. It runs in your browser, which matters: pasting a production token into a website that sends it to a server is a real leak.

The important lesson is already visible: anyone who has the token can read the payload. There is no secret involved in decoding. Never put passwords, API keys or personal data you wouldn't show the user into a JWT payload. If you need confidentiality, use encrypted tokens (JWE) or keep the data on the server.

The header

The header says how the token was signed:

alg is the signing algorithm. HS256 means HMAC with SHA-256 using a shared secret. RS256 and ES256 use a private key to sign and a public key to verify.
typ is usually JWT.
kid (key ID), when present, tells the verifier which key to use, which makes key rotation possible.

The payload and its claims

The payload holds claims: statements about the user and the token. Some names are registered by the JWT standard (RFC 7519):

Claim	Meaning	Example
`iss`	Issuer: who created the token	`https://auth.example.com`
`sub`	Subject: who the token is about	`user_123`
`aud`	Audience: who the token is meant for	`api.example.com`
`exp`	Expiration time (Unix seconds)	`1792054800`
`nbf`	Not valid before (Unix seconds)	`1792051200`
`iat`	Issued at (Unix seconds)	`1792051200`
`jti`	Unique token ID (for revocation lists)	`9f1c…`

All times are Unix timestamps in seconds, not milliseconds. exp: 1792054800 is 15 October 2026 at 09:00 UTC, exactly one hour after iat. Mixing up seconds and milliseconds is a classic bug: Date.now() in JavaScript returns milliseconds, so a token created with exp: Date.now() + 3600 expires in the year 58,000-something. Our guide to Unix timestamps covers this trap and others.

Anything else in the payload (name, role) is a custom claim your application defines.

How the signature works

The signature is what makes a JWT trustworthy. For HS256 it is:

HMAC-SHA256(secret, base64url(header) + "." + base64url(payload))

encoded with Base64URL. The server that issued the token computes this with its secret. Later, to verify the token, a server recomputes the HMAC over the first two parts and compares it with the third. If someone changes even one character of the payload (say, "role": "user" to "role": "admin"), the signature no longer matches, and the token is rejected.

With asymmetric algorithms (RS256, ES256), the issuer signs with a private key and anyone with the public key can verify. That's the standard choice when many services need to verify tokens but only one should be able to create them; the identity provider publishes its public keys at a JWKS URL.

You can see this in action with the JWT Generator: sign a payload, change one claim in the decoder, and watch verification fail.

Verifying a token step by step

Decoding is easy. Verifying means checking all of the following, in this order, and rejecting the token if any check fails:

The algorithm is the one you expect. Configure your verifier with an allow-list (for example, only RS256). Never let the token's own alg header decide.
The signature is valid for the key you trust.
exp is in the future and nbf, if present, is in the past. Allow a small clock skew (30–60 seconds) between servers.
iss is your identity provider and aud is your service. A token issued for a different application, even by the same provider, must not work on yours.
Application rules: the user still exists, the token hasn't been revoked, the claimed role is allowed.

Here is what steps 1–3 look like with Node.js's built-in crypto, to show there is no magic involved:

import { createHmac, timingSafeEqual } from 'node:crypto';

const decodePart = (part) => JSON.parse(Buffer.from(part, 'base64url').toString('utf8'));

function verifyHs256(token, secret, now = Date.now() / 1000) {
  const [h, p, s] = token.split('.');
  const header = decodePart(h);
  if (header.alg !== 'HS256') throw new Error(`Unexpected algorithm ${header.alg}`);
  const expected = createHmac('sha256', secret).update(`${h}.${p}`).digest();
  const actual = Buffer.from(s, 'base64url');
  if (actual.length !== expected.length || !timingSafeEqual(actual, expected)) throw new Error('Bad signature');
  const claims = decodePart(p);
  if (typeof claims.exp === 'number' && now >= claims.exp) throw new Error('Token expired');
  return claims;
}

Note timingSafeEqual: comparing signatures with === can leak, through response timing, how many leading bytes matched. In production, use a maintained library rather than this sketch. With the popular jose package, the full check is:

import { jwtVerify } from 'jose';

const secret = new TextEncoder().encode(process.env.JWT_SECRET);
const { payload } = await jwtVerify(token, secret, {
  algorithms: ['HS256'],
  issuer: 'https://auth.example.com',
  audience: 'api.example.com',
});

Security mistakes to avoid

Decoding instead of verifying. Functions like jwt.decode() only read the payload. Using them to make authorisation decisions means anyone can forge a token by editing the JSON. Always verify.

Trusting alg from the token. Early libraries accepted "alg": "none" (no signature at all), and some could be tricked into verifying an RS256 token as HS256 using the public key as the HMAC secret. Both attacks are stopped by an algorithm allow-list.

Weak HMAC secrets. An HS256 token can be brute-forced offline: an attacker with one token can try millions of secrets per second until the signature matches. Use at least 32 random bytes (256 bits), such as a 64-character hex string from the Random String Generator. Our article on password entropy explains why length and randomness matter.

Long lifetimes. A JWT can't easily be revoked before it expires, because verification doesn't involve a database. Keep access tokens short-lived (5–15 minutes) and use refresh tokens, which are stored and revocable, to get new ones.

Storing tokens in localStorage. Any script on your page (including one injected through an XSS bug or a compromised dependency) can read localStorage. For browser apps, an HttpOnly, Secure, SameSite cookie keeps the token out of reach of JavaScript. If you use cookies, protect state-changing requests against CSRF.

Sensitive data in the payload. Repeat after me: the payload is only encoded, not encrypted. The Base64 decoder is all anyone needs to read it, as our guide to Base64 encoding shows.

JWTs or sessions?

JWTs shine when different services must verify identity without calling a central database, which is the reason OAuth and OpenID Connect use them. For a single web application with its own backend, a classic session (a random ID in a cookie, looked up on the server) is simpler, can be revoked instantly, and keeps nothing readable on the client. Choose JWTs for what they're good at, not because they're fashionable.

Summary

A JWT is a Base64URL-encoded header and payload plus a signature over both. Anyone can read it; only the holder of the key can create a valid one. Before trusting a token, check the algorithm against an allow-list, verify the signature, and validate exp, nbf, iss and aud. Use strong secrets, short lifetimes and safe storage, and keep secrets out of the payload.

Originally published on Devtoolry, where you can also decode and verify JWTs in your browser.