DEV Community: Azam Akram

Kafka Fundamentals: Topics, Partitions, and Consumer Groups Explained the Hard Way

Azam Akram — Sat, 12 Sep 2026 12:09:31 +0000

Most developers can wire up a Kafka producer and consumer, get a message flowing end to end,
and call it done. But there are much more into it, for example, why do we go with 6 partitions instead of
3, how partitions are created, what is relationship between consumers and topic partitions etc - they seem to have no real answer.

In this blog I will cover some of very fundamentatl elements of kafka, such as, what a partition actually is,
how a message ends up on one, and how consumer groups split the work. Then I will set up a kafka broker in Docker and
break it on purpose, which will explain something very useful. Along the way I also pick up a few patterns that keep showing up once you
start building real things on top of Kafka.

The Basic Terms, in Plain English

Before any commands, it helps to get the terminologies straight. Most blogs use them loosely, and that's usually where the
confusion starts.

Cluster: a bunch of Kafka servers working as one system. You talk to "the cluster", not to any one machine in it.

Broker: a single Kafka server. It stores partitions and handles reads/writes for whatever it owns. Real clusters
run at least 3 brokers so they can survive one going down; on your laptop you'll usually just run one.

Producer / Consumer: not separate infrastructure, just code in your app. A producer sends messages, a consumer
reads them.

Topic: a named stream, like orders. Here's the twist that takes a while to understand: a topic isn't one
queue. It's a set of partitions.

Partition: the concept that takes the longest to grasp, so it gets its own section below.

Consumer group: a name you give a bunch of consumers so they can split up the work of reading a topic. More on
this further down.

Offset: just a number that goes up by one for every message, marking its position inside a partition. Offsets
are per-partition, not shared across the whole topic. There's no per-message ack, no visibility timeout like AWS SQS -
each consumer just remembers how far it's read.

Why Partitions Matter

A lot of intro material treats a topic like a plain queue: stuff goes in one end, a consumer takes it out the other,
done. That picture is wrong enough to cause real problems later. A Kafka topic is actually a durable log split into
several independent pieces. Nothing gets deleted when it's read, several consumers can each replay the whole thing at
their own pace, and how it's split up is something you decide and have to live with. That splitting is the partition,
and it's where most of the early confusion comes from - so that's next.

Partitions Aren't Copies

A very common mistake is, assuming partitions as copies of the same stream, like read replicas of a database. They
aren't. That's what replicas are - copies of one partition spread across brokers, purely for fault tolerance,
which is a different topic I'll get to another time.

Partitions are shards. Each one holds a different slice of the topic, with no overlap. It's the same idea as
sharding a database table:

Topic: "orders" with 3 partitions

Partition 0:  [order-101][order-104][order-109] ...   ← different events
Partition 1:  [order-102][order-105][order-107] ...   ← different events
Partition 2:  [order-103][order-106][order-108] ...   ← different events

order-101 only ever lives in one partition. Put all the partitions together and you get the full topic; on their
own, none of them looks like any of the others. Two things fall out of this:

Order is only guaranteed inside a single partition. Messages in partition 0 stay in order relative to each other. A message in partition 0 and one in partition 1 have no ordering relationship at all - Kafka makes no promises there.
Different consumers can read different partitions at the same time. This is really the whole reason Kafka can scale the way it does.

How Kafka Decides Which Partition a Message Goes To

This comes down to the partition key, something you choose when you send a message. Kafka hashes it and always
maps that hash to the same partition. Same key in, same partition out, every time - as long as the partition count
doesn't change.

Say you've got a customer-orders topic. A few ways to key it:

By customer_id: every event for one customer lands on the same partition, so ordering within a customer (say CREATED before SHIPPED) is guaranteed. Different customers still spread out across partitions, so you keep the parallelism.
By order_id: good when a single order's events need to stay in order, but you don't care how one customer's different orders relate to each other.
No key at all: Kafka spreads messages around over time for max throughput, with no ordering guarantee (more on the batching behaviour behind this a bit further down). Fine for something like clickstream events where order genuinely doesn't matter.

The question to actually ask yourself: which entity's events need to stay in order relative to each other? Whatever
that is, that's your key.

One thing worth knowing upfront: if you key by customer_id and one customer is way more active than the rest, their
partition turns into a hot spot - it's pinned to one broker and one consumer thread, so it takes all the load while
everyone else's partition sits comfortably. Real production headache, and the only way around it is thinking about key
design before you hit it.

How Many Partitions Should You Actually Use

This is a separate call from the key, and mixing the two up is a common next mistake. The key decides where a given
message goes. The count decides how many shards the topic has, full stop - it's about capacity and parallelism,
not about your business domain.

The rule that actually matters: only one consumer in a group can read a given partition at a time. So the
partition count is a hard cap on how much you can parallelise. A topic with 4 partitions will never be processed by
more than 4 consumers in the same group - deploy a fifth and it just sits there doing nothing.

A rough way to size it:

target_throughput = 100 MB/sec
single_partition_throughput ≈ 10 MB/sec (hardware/network dependent)

partitions needed ≈ 100 / 10 = 10 (minimum, then round up for headroom)

A few other things feed into the number: how slow your per-message processing is (slower downstream calls need more
partitions to keep up), how much you expect to grow (bumping the partition count later changes the key-to-partition
mapping and breaks ordering guarantees you already had, so most people just over-provision early), and broker
overhead (more partitions means more file handles and replication traffic per broker, and there's a real ceiling).

There's no "business" answer to partition count, and that's the thing to unlearn. The domain logic belongs in the
key. The count is just infra sizing, decided once, and annoying to change later.

Consumer Groups: How the Work Actually Gets Split Up

A consumer group is just a name you give a set of consumers that want to share the work of reading a topic. Any
consumer that starts up with the same group ID joins that group, and Kafka handles splitting the topic's partitions
between them.

This is where the partition-count rule from above actually bites: Kafka gives each partition to exactly one consumer
in the group at a time. More consumers than partitions and some sit idle. More partitions than consumers and some
consumers end up handling several.

Every time a consumer joins or drops out, Kafka triggers a rebalance - it works out a fresh split of the partitions
across whoever's left and hands out ownership again. That's the whole trick behind scaling up: start another instance
of your consumer with the same group ID, and Kafka does the rest. No code change needed.

There's a less obvious perk to grouping this way too: broadcasting. Two different consumer groups reading the same
topic each get their own full copy of every message. Say billing-service is one group and analytics-service is
another - both see everything, both track their own offsets, and neither one affects the other. Inside a group, Kafka
acts like a queue: one message, one consumer. Across groups, it acts like pub/sub: every group gets everything. Same
underlying log, both patterns at once.

Trying It on a Local Broker

Got a Kafka container running, with the scripts under /opt/kafka/bin added to PATH so I didn't have to type the
full path every time:

export PATH=$PATH:/opt/kafka/bin

Created two topics so I could compare them side by side:

kafka-topics.sh --create --topic orders-1p \
  --bootstrap-server localhost:9092 \
  --partitions 1 --replication-factor 1

kafka-topics.sh --create --topic orders-12p \
  --bootstrap-server localhost:9092 \
  --partitions 12 --replication-factor 1

--describe on orders-12p shows all 12 partitions, all led by broker 1 (single-broker setup, so nothing interesting
happening on the replication side yet):

Topic: orders-12p   PartitionCount: 12   ReplicationFactor: 1
    Partition: 0   Leader: 1   Replicas: 1   Isr: 1
    Partition: 1   Leader: 1   Replicas: 1   Isr: 1
    ...

Watching the Consumer Limit Play Out

Started three console consumers, all in the same group, pointed at the 1-partition topic:

kafka-console-consumer.sh --topic orders-1p \
  --bootstrap-server localhost:9092 \
  --group test-group-1p \
  --formatter-property print.partition=true

Then sent a few messages. Only one of the three consumers got anything. The other two just sat there, connected
and doing nothing - which is exactly the point. Checking the group directly backs it up:

kafka-consumer-groups.sh --bootstrap-server localhost:9092 --describe --group test-group-1p

GROUP           TOPIC       PARTITION  CURRENT-OFFSET  LOG-END-OFFSET  LAG  CONSUMER-ID
test-group-1p   orders-1p   0          22              22              0   console-consumer-...

One row. One partition, one consumer doing anything. The other two are members of the group, but they own nothing.

Ran the same test against the 12-partition topic, giving all three consumers a few seconds to settle before
producing anything, and this time the split was clean:

console-consumer-A → partitions 0, 1, 2, 3
console-consumer-B → partitions 4, 5, 6, 7
console-consumer-C → partitions 8, 9, 10, 11

Exactly what you'd expect: 12 partitions, 3 consumers, 4 each.

Why 10 Unkeyed Messages All Landed in One Partition

This one threw me for a minute. With all three consumers sitting evenly assigned, I sent 10 messages with no key and
expected them to spread out. Instead, all 10 landed in the same partition, and only one consumer terminal lit up.

My first thought was that the rebalance was broken. It wasn't - --describe still showed a perfectly even split. What
was actually happening: when you produce without a key, Kafka doesn't round-robin each message individually. The
producer uses what's called a sticky partitioner - it picks one partition and sticks with it for a whole batch (until
the batch fills up or linger.ms runs out), then switches to a different one for the next batch. I'd typed those 10
lines quickly into the console producer, so they got batched together and shipped as one unit to a single partition.

That's not a quirk, it's a real thing to know about before you hit it in production. Sticky partitioning trades
perfectly even spread for fewer, bigger batches and better throughput - it evens out over many batches, not
necessarily over a handful of messages typed by hand. Key your messages explicitly, though, and you get the same
result every time, no batching surprises involved.

Patterns That Show Up Once You Build on Top of This

Once partitions, keys, and consumer groups make sense, most of what you see in real Kafka systems turns out to be a
small handful of patterns built on top of them:

Dead letter queue (DLQ). A message that keeps failing after a few retries goes to a separate <topic>-dlt topic instead of blocking the partition or getting silently dropped. The main consumer keeps moving, and the failed messages sit somewhere you can actually go look at them. I walk through building one in Building Kafka Producer-Consumer Using Go and Docker.
Retry with backoff. The simple version: retry a failed message a few times with a short delay before giving up and sending it to the DLQ (also in the post above). At bigger scale, that retry often moves to its own topic (<topic>-retry-30s, <topic>-retry-5m) so a slow downstream doesn't hold up the main partition while messages wait around.
Idempotent consumer. Kafka's default guarantee is at-least-once, so every consumer has to assume a message might show up twice - say, after a rebalance like the one above, or a commit that got retried. The fix lives on the consumer side, not the broker: keep track of a message's unique key (or a hash of its contents) somewhere, and skip anything you've already handled.
Transactional outbox. The problem: a service can't save to its own database and publish a Kafka event as one all-or-nothing step. One can succeed while the other fails, and now the database and Kafka disagree - either the order got saved but nobody heard about it, or Kafka says the order exists when it was never actually saved. The fix: don't publish to Kafka directly. Save the event as a row in an outbox table instead, in the same database transaction as the real write. That part is now truly atomic - both rows are saved, or neither is. Getting the event into Kafka happens afterward, as a separate step:
- Polling - a background job checks the outbox table now and then, publishes anything new, and marks it done.
- CDC via Kafka Connect - watches the database's own internal change log for new rows and streams them to Kafka automatically, no polling needed.

On cleanup: don't delete a row the moment it's published - just mark it published, and let a separate scheduled
job purge old published rows later (say, once a day). That way a crash right after publishing doesn't lose the
record before you're sure Kafka got it, and the table doesn't grow forever either.

The database write stays the single source of truth and stays atomic; publishing becomes a "happens shortly after"
step instead of a "must happen right now" one - the database and Kafka are eventually consistent, not instantly
consistent - and the event can't be lost since it sits safely in the outbox table until it's confirmed published.
The cost: it's at-least-once, not exactly-once, so consumers still need to be
idempotent (as above), there's a small delay before events show up, and you're now running an extra table plus a
poller or CDC pipeline.

Fan-out through separate consumer groups. Already covered above - every group reading a topic gets its own full copy of the stream. It's what lets billing-service and analytics-service both read orders independently, without either one's speed or downtime touching the other.

None of these are switches you flip in Kafka itself - they're just conventions you build into your producers and
consumers on top of the same partitions, keys, and groups covered above.

What I Actually Walked Away With

The mental model that finally stuck after all this:

Concept	What it actually is
Partition	A shard - a different, non-overlapping slice of the topic's events
Partition key	Decides which partition a given message lands on
Partition count	A capacity and parallelism decision, fixed at topic creation, expensive to change later
Consumer group	A set of consumers sharing the work of a topic; one partition → one active consumer at a time within a group
Offset	Per-partition read position, tracked separately by each consumer group
At-least-once delivery	The default guarantee - consumers need to be idempotent, not assume single delivery

Next up, when I get to it: multi-broker replication and leader election, and how retention and compaction actually
work.

SQL Formatter

Azam Akram — Fri, 03 Jul 2026 15:47:45 +0000

SQL formatter instantly formats and beautifies the SQL queries for any database. It supports MySQL, PostgreSQL, T-SQL, SQLite, BigQuery, and more.

Formatting options explained

Dialect: Controls dialect-specific syntax rules. For example, PostgreSQL supports :: casting, T-SQL uses TOP instead of LIMIT, and BigQuery uses backtick identifiers.
Keywords UPPERCASE: The most common SQL style guide convention. Makes reserved words like SELECT, FROM, and WHERE visually distinct from column and table names.
Commas before: Places commas at the start of each line (,column_name). Popular in data warehousing teams and dbt style guides - easier to comment out a column without breaking the query.
Commas after: Standard convention in most SQL editors and ORMs (column_name,).

Common use cases

Readable queries from ORMs, query builders, or database console output.
Enforce a consistent style across team SQL files before committing.
Unminify hand-written one-liners for debugging in production logs.
Format EXPLAIN queries before sharing with a teammate.
Prepare SQL snippets for documentation, blog posts, or code review.

How to Use This SQL Formatter

SQL formatter is designed for quick browser-based work when you need to format sql for 10+ database dialects. Paste or select your input in the tool area above, run the conversion or formatting step, then review the result before copying it into code, documentation, tickets, test data, or an API client.

Example input
select id,name from users where active=true order by created_at desc

Example output
SELECT id, name FROM users WHERE active = true ORDER BY created_at DESC

When to Use This Tool

Make a long query readable before code review
Normalize copied SQL from logs or dashboards
Prepare database examples for docs, tickets, or migration notes

Accepted Input Formats

SQL queries from MySQL, PostgreSQL, SQLite, BigQuery, T-SQL, and similar dialects
Single statements, multi-statement scripts, and copied query logs
Minified SQL that needs consistent indentation and keyword casing

Output Details

The output keeps the same query logic while improving layout
Keyword case and indentation follow the options selected in the tool

Related Tools
JavaScript Beautifier and Formatter
Beautify or format JavaScript online instantly. Paste minified or messy JS and get clean, readable, indented code. Free JS beautifier and formatter, no sign-up.

CSS Beautifier and Formatter
Beautify, format, or prettify CSS online for free. Unminify compressed stylesheets into clean, readable code. Free CSS beautifier and formatter, no sign-up.

YAML Formatter & Validator
Format, beautify, and validate YAML online. Supports Kubernetes, Docker Compose, GitHub Actions, Ansible, and Helm. Syntax errors reported with line and column numbers.

Legacy system needs XML but you're living in JSON world? One paste, done. https://www.solutiontoolkit.com/tools/json-to-xml-converter #xml #json #validate

Azam Akram — Tue, 30 Jun 2026 19:55:58 +0000

solutiontoolkit.com

Gzip Base64 encoder / decoder

Azam Akram — Sun, 28 Jun 2026 15:44:55 +0000

Compress text with Gzip and encode the result as Base64 in a single step — or go the other way and decode then decompress a Base64 payload back to the original string. Everything runs in your browser.

https://www.solutiontoolkit.com/tools/gzip-base64-encoder-decoder

When is this useful?

API payloads: some services accept compressed, Base64-encoded bodies to reduce bandwidth. Decode them here to inspect the original JSON or XML.
Environment variables: large config blobs are often Gzip+Base64 encoded before being stored as env vars or Kubernetes secrets.
CloudWatch / logging: AWS Lambda logs shipped via Kinesis are Gzip+Base64 encoded. Paste the payload here to read the raw log lines.
Cookie compression: session cookies containing JSON are sometimes compressed to stay under browser size limits.

How it works

Compress & Encode: runs Gzip compression on your text using the pako library, then encodes the binary output as a Base64 string safe for transport in JSON, URLs, and headers.
Decompress & Decode: validates the Base64 format, decodes the bytes, then runs Gzip inflate to recover the original text.

Note: Short strings often produce a larger Base64 output than the original because Gzip's header and Base64 expansion (x1.33) outweigh the compression gain. Gzip shines on repetitive text over ~1 KB.

How to Use This Gzip Base64 Decoder and Encoder

gzip base64 decode is designed for quick browser-based work when you need to gzip compress text. Paste or select your input in the tool area above, run the conversion or formatting step, then review the result before copying it into code, documentation, tickets, test data, or an API client.

Example input:
Gzip-compressed Base64 API payload

Example output:
H4sIAAAAAAAAA3OvyizQTc7PLShKLS5OTVFwSixONTNRcAzwVChIrMzJT0wBAOnU+sEiAAAA

Common Issues to Check

A normal Base64 string will not decompress unless the decoded bytes are gzip data
Copied payloads can fail when quotes, escaping, or whitespace are included
Very large payloads can take longer because compression happens in the browser

Stop rewriting configs by hand. Paste JSON, get YAML (or the other way around) in one click. https://www.solutiontoolkit.com/tools/json-yaml-converter #json #yaml

Azam Akram — Sun, 28 Jun 2026 15:36:03 +0000

solutiontoolkit.com

Your API wants JSON. Your config is YAML. Convert it here, no signup needed. https://www.solutiontoolkit.com/tools/yaml-to-json-converter #json #yaml

Azam Akram — Sat, 27 Jun 2026 23:42:12 +0000

solutiontoolkit.com

Stop rewriting configs by hand. Paste JSON, get YAML (or the other way around) in one click. https://www.solutiontoolkit.com/tools/json-yaml-converter #json #yaml #converter

Azam Akram — Sat, 27 Jun 2026 23:40:03 +0000

solutiontoolkit.com

Tired of pasting JSON into random sites? Here's a free in-browser validator - nothing leaves your machine. https://www.solutiontoolkit.com/tools/validate-and-prettify-json #json #pretty #validate

Azam Akram — Sat, 27 Jun 2026 23:37:58 +0000

solutiontoolkit.com

Check live scores, full group stage schedule, and knockout fixtures all in one place: 👉 https://www.solutiontoolkit.com/world-cup-2026/schedule #WorldCup2026 #FIFA2026 #NextJS #SolutionToolkit #WebDev #Football

Azam Akram — Thu, 25 Jun 2026 23:18:46 +0000

solutiontoolkit.com

Debugging GZip Base64 compressed payloads from AWS API Gateway / Lambda

Azam Akram — Mon, 22 Jun 2026 17:40:12 +0000

You call an API. The response comes back and one of the fields looks like this:

H4sIAAAAAAAAE6tWKkktLlGyUlIqS04sLknMSwUAAAD//wMAAAD//w==

If you have ever looked at something like that wondering what is hiding inside, you are looking at a GZip-compressed payload encoded in Base64.

This pattern appears more often than you might expect — in AWS, Azure, Kafka, webhook systems, and internal microservices. Understanding why it exists and how to quickly decode it will save you time every time you hit it.

Just need to decode one now? Paste the string into the GZip Base64 Encoder / Decoder and get the result instantly — no terminal required.

The Problem: Binary Data in Text Channels

GZip compression produces binary output — raw bytes that can include any value from 0 to 255. Most text-based protocols (HTTP headers, JSON fields, environment variables, message queues) are designed for printable characters. If you try to embed raw binary bytes into a JSON string, you will get parsing errors or silent data corruption.

Base64 solves this by converting binary data into a safe alphabet of 64 printable ASCII characters. The trade-off is a roughly 33% increase in size — but after GZip compression, the total payload is still significantly smaller than the original.

Why APIs Combine GZip and Base64

The two techniques solve different problems and work well together:

GZip reduces size. For repetitive, structured data like JSON or XML, GZip typically achieves 60–80% compression. A 100 KB JSON payload can compress to 15–20 KB.

Base64 makes binary data safe to transport. It guarantees the compressed bytes can be embedded in a JSON field, stored in a database column, passed through an environment variable, or included in a URL query string without corruption.

Together they allow a system to transmit large, structured payloads efficiently through channels that only support text.

Real-World Examples

AWS Lambda and API Gateway — response bodies larger than a certain threshold can be returned as Base64-encoded compressed content, with a flag telling the client to decompress
Kafka messages — event payloads are often GZip + Base64 encoded before publishing so they fit within message size limits and serialize cleanly
Webhook events — third-party services sometimes send compressed event data to reduce egress costs
Distributed tracing / logging — trace context or structured log data embedded in HTTP headers

How to Debug a Compressed Payload

When you encounter one of these strings during development or debugging, the workflow is straightforward:

Copy the encoded string from the API response, log line, or message payload
Decode the Base64 layer to recover the GZip binary
Decompress the GZip to recover the original data

In a terminal you can do this with:

echo "H4sIAAAAAAAAE6tWKkktLlGyUlIqS04sLknMSwUAAAD//wMAAAD//w==" \
  | base64 --decode \
  | gunzip

That works fine in a Linux or macOS shell. On Windows, or when you just want a quick result without opening a terminal, an online tool is faster.

Decode It Instantly

The GZip Base64 Encoder / Decoder tool on this site handles both directions — paste your encoded string to decode it, or paste plain text and JSON to compress and encode it. No installation, no terminal, works in the browser with no data leaving your machine.

It is useful when you need to inspect a payload quickly during an incident, verify what a service is actually sending before writing decoding logic in your application, or compress test data to embed in a config or environment variable.

The next time you hit an unreadable string in an API response, you will know exactly what it is and how to open it up.

Generate MD5, SHA-1, SHA-256, and SHA-512 Hashes Instantly in Your Browser

Azam Akram — Thu, 18 Jun 2026 17:32:40 +0000

A free, client-side tool for hashing text — no installation, no account, no server.

What Is a Hash and When Do You Need One?

A hash function takes any input — a word, a sentence, a JSON blob — and produces a fixed-length string of characters. The same input always produces the same output. Change even a single character and the output changes completely.

Developers reach for hashing in a surprisingly wide range of situations:

Verifying data integrity — confirm a file or string has not been tampered with
Checksums — compare two pieces of data without storing or transmitting the originals
Password storage — store a hash instead of a plaintext password (with a proper algorithm)
Caching and deduplication — use a hash as a unique key for a piece of content
Debugging — quickly fingerprint a string to check if two values are identical across environments
The Text Hash Generator lets you generate hashes across all four commonly used algorithms in one step, directly in your browser.

The Four Algorithms

MD5–128-bit MD5 is fast and widely recognised. It is no longer considered cryptographically secure for security-sensitive use cases, but remains practical for checksums, non-security fingerprinting, and working with legacy systems that expect MD5 output.

SHA-1–160-bit SHA-1 is similarly deprecated for security use but still appears in older protocols, version control systems, and certificate chains. Useful when you need to match or verify a SHA-1 value produced by another system.

SHA-256–256-bit SHA-256 is the workhorse of modern cryptography. It is part of the SHA-2 family and is widely used in TLS certificates, code signing, blockchain, and general-purpose integrity verification. When in doubt, use SHA-256.

SHA-512–512-bit SHA-512 produces a longer digest and offers a higher security margin. It is preferred in high-security contexts and, on 64-bit processors, can actually be faster than SHA-256 due to how modern CPUs handle 64-bit operations.

What the Tool Does

Open the Text Hash Generator, type or paste any text, and click Generate Hashes (or press Ctrl+Enter). All four hashes are computed and displayed simultaneously.

Uppercase toggle Switch between lowercase and uppercase hex output with a single checkbox. Some systems expect uppercase hash strings — this saves you a manual conversion step.

Copy individual or all Each hash has its own Copy button. There is also a Copy all hashes option that puts all four results on the clipboard in a labelled format, ready to paste into documentation or a ticket.

Character count The input field shows a live character count as you type, useful when you need to know the exact length of the string you are hashing.

How It Works

SHA-1, SHA-256, and SHA-512 are computed using the browser’s built-in Web Crypto API via crypto.subtle.digest. MD5 is handled by the js-md5 library, since MD5 is not included in the Web Crypto API (intentionally — browsers do not endorse it for cryptographic use). All four run client-side. Open DevTools, go to the Network tab, type some text, and generate — you will see zero outbound requests.

Try It
Open the Text Hash Generator — paste any text and get all four hashes in one click.

The Text Hash Generator is one of several developer tools at SolutionToolkit. All tools run client-side with no server-side processing.

A Client-Side JWT Debugger That Runs Entirely in Your Browser

Azam Akram — Thu, 18 Jun 2026 13:08:27 +0000

Why Another JWT Tool?
Most JWT debugging workflows involve copying a token into an online tool, inspecting the payload, and moving on. That works fine for simple use cases, but falls short when you need to do more — sign a token with a specific algorithm, verify a signature against a public key, or quickly check whether a token has expired.

The JWT Debugger is a free, browser-based tool that covers the full JWT workflow: decode, inspect, sign, and verify — all in one place, with no installation and no account required.
What It Does

Decode and inspect Paste any JWT and the tool splits it into header, payload, and signature — colour-coded so each part is visually distinct. Timestamp claims (iat, exp, nbf) are automatically converted to human-readable dates with a relative time display ("expires in 2h", "3 days ago").

Status at a glance A badge shows whether the token is Active, Expired, or has No Expiry set. If a token is expired, you see exactly how long ago — no manual Unix timestamp conversion needed.

Sign tokens Build a header and payload from scratch and sign them. All twelve standard algorithms are supported:

FamilyAlgorithmsHMACHS256, HS384, HS512RSA PKCS#1RS256, RS384, RS512RSA-PSSPS256, PS384, PS512ECDSAES256, ES384, ES512

For HMAC algorithms, enter your shared secret. For asymmetric algorithms, paste your PKCS#8 private key. The tool signs the token locally using crypto.subtle.sign and gives you the complete JWT.

Verify signatures Paste a JWT and your key, click Verify, and the tool confirms whether the signature is valid. For RSA and ECDSA, paste the public key in SPKI PEM format. Verification runs entirely in crypto.subtle.verify.

Edit and re-encode Modify the header or payload JSON and the encoded token updates in real time. Useful for quickly testing how a claim change affects the token structure, or for building a test token before signing it.

How It Works Under the Hood
The tool is built on the Web Crypto API — a browser-native cryptography interface available in all modern browsers. There are no third-party cryptography libraries. Every signing and verification operation calls crypto.subtle directly.

Base64url encoding and decoding are handled with TextEncoder and atob/btoa. PEM keys are stripped of their headers and decoded from base64 before being passed to crypto.subtle.importKey. The signing input follows the JWT spec — base64url(header) + "." + base64url(payload) — and the resulting signature bytes are base64url-encoded and appended as the third segment.

If you want to verify the behaviour yourself: open DevTools, go to the Network tab, and paste a token. You will see zero outbound requests.

Try It
Open the JWT Debugger and paste any JWT into the top field. The decoded header and payload appear immediately. No account, no signup.

If you want to understand the theory behind what you are looking at — how the header, payload, and signature fit together, what RS256 means, and how the private/public key split works — the companion article JWT Shared Secret: How JWTs are Signed and Shared Across Services covers the fundamentals.

The JWT Debugger is one of several developer tools at SolutionToolkit. All tools run client-side with no server-side processing.

DEV Community: Azam Akram

Kafka Fundamentals: Topics, Partitions, and Consumer Groups Explained the Hard Way

The Basic Terms, in Plain English

Why Partitions Matter

Partitions Aren't Copies

How Kafka Decides Which Partition a Message Goes To

How Many Partitions Should You Actually Use

Consumer Groups: How the Work Actually Gets Split Up

Trying It on a Local Broker

Watching the Consumer Limit Play Out

Why 10 Unkeyed Messages All Landed in One Partition

Patterns That Show Up Once You Build on Top of This

What I Actually Walked Away With

Further reading

SQL Formatter

Formatting options explained

Common use cases

How to Use This SQL Formatter

When to Use This Tool

Accepted Input Formats

Output Details

Legacy system needs XML but you're living in JSON world? One paste, done. https://www.solutiontoolkit.com/tools/json-to-xml-converter #xml #json #validate

Gzip Base64 encoder / decoder

When is this useful?

How it works

How to Use This Gzip Base64 Decoder and Encoder

Stop rewriting configs by hand. Paste JSON, get YAML (or the other way around) in one click. https://www.solutiontoolkit.com/tools/json-yaml-converter #json #yaml

Your API wants JSON. Your config is YAML. Convert it here, no signup needed. https://www.solutiontoolkit.com/tools/yaml-to-json-converter #json #yaml

Stop rewriting configs by hand. Paste JSON, get YAML (or the other way around) in one click. https://www.solutiontoolkit.com/tools/json-yaml-converter #json #yaml #converter

Tired of pasting JSON into random sites? Here's a free in-browser validator - nothing leaves your machine. https://www.solutiontoolkit.com/tools/validate-and-prettify-json #json #pretty #validate

Check live scores, full group stage schedule, and knockout fixtures all in one place: 👉 https://www.solutiontoolkit.com/world-cup-2026/schedule #WorldCup2026 #FIFA2026 #NextJS #SolutionToolkit #WebDev #Football

Debugging GZip Base64 compressed payloads from AWS API Gateway / Lambda

The Problem: Binary Data in Text Channels

Why APIs Combine GZip and Base64

Real-World Examples

How to Debug a Compressed Payload

Decode It Instantly

Generate MD5, SHA-1, SHA-256, and SHA-512 Hashes Instantly in Your Browser

What Is a Hash and When Do You Need One?

The Four Algorithms

What the Tool Does

How It Works

A Client-Side JWT Debugger That Runs Entirely in Your Browser