pigia.dev — Guides & Developer Resources

How JWT Decoding Differs From JWT Verification

Fri, 20 Mar 2026 00:00:00 GMT

Guide

How JWT Decoding Differs From JWT Verification

Learn what a JWT decoder can and cannot tell you, why reading claims is not the same as trusting them, and where exp, iat, and nbf fit in.

Quick answer

Decoding a token does not prove the sender is trusted.
Verification checks the signature, algorithm, and key relationship.
Use decoding for inspection and verification for trust decisions.

What decoding gives you

Decoding reveals the header and payload sections so you can inspect claims like sub, aud, iat, nbf, and exp. This is useful for debugging authentication flows, checking obvious mistakes, and verifying that the application is at least sending the fields you expect.

It does not prove that the token was issued by the system you expect. Anyone can construct a JWT-looking string with arbitrary claims, so a decoded payload is still untrusted data.

What verification adds

Verification checks the token signature and, depending on your implementation, validates critical claims like issuer, audience, expiry, and not-before time. That is the security boundary.

If your application trusts claims before signature validation, you have a logic bug. The right mental model is simple: decoding is inspection, verification is trust.

Common debugging traps

Developers often decode a token, see a valid-looking payload, and assume authentication should work. In practice, failures usually come from a bad signing key, a clock skew problem, an issuer mismatch, or an audience mismatch.

That is why it helps to inspect time-based claims separately. Converting iat, nbf, and exp into readable dates quickly exposes many integration mistakes.

Useful local tooling

Use the JWT Decoder & Inspector to read claims locally, the Timestamp Converter to inspect claim times, and the Base64 tool if you need to inspect individual token segments manually.

Read on pigia.dev

JSON vs XML: Which Format Should You Use?

Fri, 20 Mar 2026 00:00:00 GMT

Comparison

JSON vs XML: Which Format Should You Use?

Compare JSON and XML for APIs, configuration files, feeds, and enterprise integrations. Includes practical guidance on readability, schema support, and tooling.

Quick answer

Use JSON for REST APIs, browser apps, configuration, and most modern integrations.
Use XML for document-heavy workflows, SOAP, RSS or Atom feeds, and systems that depend on XSD validation or namespaces.

Where JSON is stronger

JSON is lighter, easier to read, and maps naturally to JavaScript objects. That makes it faster to inspect in browsers, easier to serialize in modern backends, and cheaper to move over the network.

For most teams building internal tools, dashboards, mobile apps, or public APIs, JSON lowers implementation friction. It is also the default for many developer tools, documentation systems, and API clients.

Where XML is still the better choice

XML becomes useful when the data model needs attributes, namespaces, ordered mixed content, or formal schema validation. That is common in publishing, enterprise integrations, and some finance or government systems.

It is also still the format behind a lot of feeds, build files, manifests, and older but business-critical APIs.

What developers usually need in practice

If you are debugging payloads all day, readability matters more than ideology. The practical answer is to keep both tools nearby and format whichever payload your environment emits.

For day-to-day work, use the JSON Formatter for API payloads and the XML Formatter for feeds, manifests, and integration payloads.

Read on pigia.dev

Unix Timestamp Seconds vs Milliseconds

Fri, 20 Mar 2026 00:00:00 GMT

Guide

Unix Timestamp Seconds vs Milliseconds

Learn how to recognize 10-digit and 13-digit Unix timestamps, avoid date parsing mistakes, and safely convert timestamps from logs, APIs, and databases.

The shortcut

10 digits usually means seconds. 13 digits usually means milliseconds.

That rule covers most timestamps from Unix commands, server logs, JavaScript, and API payloads, even though there are edge cases with older or future values.

Why this happens

Unix time was historically measured in seconds. Many modern runtimes, especially JavaScript, expose timestamps in milliseconds because it is easier for UI code and timers.

Date.now() returns milliseconds. Many CLI tools and backend logs still emit seconds, so the same workflow can produce both formats on the same day.

How to sanity-check a suspicious value

If a converted date lands near January 1970, you probably treated milliseconds as seconds. If the result lands absurdly far in the future, you probably treated seconds as milliseconds.

Checking the digit length before conversion is the fastest way to avoid that mistake in logs, SQL queries, and auth claim debugging.

Safe workflow

Check the length first, then convert. If the value looks suspicious after conversion, verify whether you need to multiply or divide by 1000.

The Timestamp Converter on pigia.dev detects this automatically and shows multiple output formats so you can sanity-check the result fast.

Read on pigia.dev

When Base64 Is Useful and When It Is Not

Fri, 20 Mar 2026 00:00:00 GMT

Workflow

When Base64 Is Useful and When It Is Not

Understand where Base64 fits in HTTP, JWTs, data URIs, and file transport, plus the common mistake of treating Base64 like encryption.

Good use cases

Encoding assets in data URIs, transporting binary data inside JSON or XML payloads, debugging HTTP Basic Auth headers, and inspecting encoded application data are all normal uses.

Developers also encounter Base64 inside JWT segments, email MIME payloads, and file upload flows. In those cases, Base64 is a packaging format, not a security boundary.

What Base64 does not do

It does not hide data from anyone. It does not protect credentials. If a secret is only Base64-encoded, it is still exposed to anyone who sees the value.

Use encryption for confidentiality and hashing for integrity or one-way verification, depending on the problem you are solving.

Where teams get confused

People often see an unreadable string and assume it is encrypted. That leads to weak security reviews and bad documentation. The right question is not whether it looks random, but whether it was actually protected with a cryptographic system.

If you can decode it instantly in the browser with no key, it is encoding, not encryption.

Practical tooling

Use the Base64 Encoder / Decoder when you need to inspect or transform encoded payloads, and the Hash Generator when you need a digest for integrity checks.

Read on pigia.dev

UUID vs GUID: Differences That Matter in Practice

Fri, 20 Mar 2026 00:00:00 GMT

Comparison

UUID vs GUID: Differences That Matter in Practice

See how UUID and GUID terminology maps across RFC 4122, Microsoft tooling, databases, and APIs, and when formatting options matter.

The practical answer

UUID is the standards-oriented term. GUID is the Microsoft-oriented term. Most teams treat them as interchangeable unless a specific platform documents otherwise.

What matters more is the version, formatting rules, and whether your database or API expects hyphens, uppercase, or lowercase values.

Where confusion shows up

Documentation, ORMs, and cloud products often mix the terms. That can make developers think they need two different generators when they usually do not.

If the wire format is the same, your real job is to emit the expected casing and hyphen style consistently across systems.

Version matters more than the label

When an implementation detail matters, it is usually because one system expects random UUIDs, another prefers sortable IDs, or a database index behaves differently depending on insertion order.

That means version choice and formatting policy are higher-value decisions than the UUID versus GUID label itself.

Generate the format you need

The UUID Generator lets you generate v4 identifiers and switch casing or hyphens depending on what your database, API, or legacy system expects.

Read on pigia.dev

How Query Strings Handle Spaces, Arrays, and Duplicate Keys

Fri, 20 Mar 2026 00:00:00 GMT

Guide

How Query Strings Handle Spaces, Arrays, and Duplicate Keys

Understand how query strings encode spaces, repeated parameters, nested redirect URLs, and array-like values across browsers and frameworks.

Spaces and special characters

Spaces are commonly encoded as %20 or +, depending on the encoder and context. Reserved characters like &, =, and ? must be encoded when they belong to the value, not the query syntax itself.

That distinction becomes important when a value itself contains a URL, JSON, or a search expression with operators.

Duplicate keys and arrays

Many frameworks represent arrays as repeated keys like tag=one&tag=two. Others use bracket syntax. If your parser silently keeps only the last value, you can lose important context while debugging.

That is why copying the raw URL into a parser is often more reliable than trying to reason about the string visually.

Nested redirect URLs

Redirect and callback parameters usually contain full URLs inside a query value, which means the nested URL itself must be encoded. That is the fastest path to unreadable URLs and copy-paste mistakes.

Auth flows, payment redirects, and tracking parameters make this pattern common in production systems.

Debugging workflow

Use the Query String Parser to inspect the decoded parameter set, and the URL Encode / Decode tool when you need to isolate one value and re-encode it safely.

Read on pigia.dev

When JSON to CSV Conversion Breaks Down

Fri, 20 Mar 2026 00:00:00 GMT

Workflow

When JSON to CSV Conversion Breaks Down

See where JSON-to-CSV conversion works well, where nested structures get messy, and how to prepare API payloads for spreadsheet-friendly exports.

Where conversion works well

Arrays of objects with stable fields are ideal. API exports, user lists, event summaries, and analytics rows usually convert cleanly into a spreadsheet-ready format.

If every row mostly shares the same keys, CSV is an efficient handoff format for operations, support, and finance workflows.

Where it gets messy

Nested objects, arrays inside cells, and records with wildly different keys often produce CSV output that is technically correct but hard to analyze. In those cases, flatten or normalize the source first.

Optional fields are manageable; unpredictable shapes are not. Once columns start exploding, the output stops being useful to the people who need it.

How to decide before converting

Ask whether the final consumer needs a table or a document. CSV is good for rows, filters, joins, and spreadsheet workflows. It is bad at preserving nested structure and relationships without extra transformation rules.

If the original data is deeply nested, keep the JSON as the source of truth and derive a flattened export for the specific reporting job.

Practical workflow

Format and inspect the payload first with the JSON Formatter, then convert the array with the JSON to CSV Converter once you know the structure is flat enough for a table.

Read on pigia.dev

Regex Flags Explained: What g, i, m, s, and u Actually Do

Sat, 21 Mar 2026 00:00:00 GMT

Guide

Regex Flags Explained: What g, i, m, s, and u Actually Do

Understand what regex flags change in practice, including global matching, case-insensitive matching, multiline anchors, dotAll behavior, and Unicode handling.

Quick answer

g finds all matches instead of stopping after the first one.
i ignores case differences.
m makes ^ and $ work per line instead of only at the start and end of the whole string.
s lets . match newline characters.
u enables more correct Unicode-aware behavior.

What regex flags do

A regex pattern does not run in isolation. Flags, also called modifiers, change how the engine interprets that pattern. That is why the same expression can return one match, many matches, or no matches at all depending on which flags are enabled.

If you debug regexes in JavaScript, TypeScript, or browser tooling, these flags are often the first thing to check when a pattern behaves unexpectedly.

The global flag: `g`

The global flag tells the engine to keep scanning for every match instead of stopping after the first one. That matters when you are extracting repeated values from logs, URLs, or free-form text.

Without g, a pattern like \d+ against Order 12, 45, 900 returns only the first number. With g, it can return all three matches.

The case-insensitive flag: `i`

The i flag makes letter matching ignore uppercase versus lowercase differences. That is useful for user input, HTTP headers, and loosely formatted text where casing is inconsistent.

A pattern like error will miss ERROR and Error unless you add i. This is one of the most common reasons a regex looks correct but returns no matches.

The multiline flag: `m`

The multiline flag changes how the anchors ^ and $ work. Without m, they only refer to the start and end of the entire string. With m, they also match the start and end of each line.

That makes ^ERROR useful for scanning multi-line logs line by line instead of only checking whether the entire text begins with ERROR.

The dotAll flag: `s`

Normally the dot character . does not match newline characters. The s flag changes that so a dot can span across line breaks.

This matters when you are trying to capture blocks of text, stack traces, or multi-line snippets. If your pattern works on one line but breaks on pasted content, missing s is a common cause.

The Unicode flag: `u`

The u flag tells the engine to interpret the pattern with Unicode awareness. This is important for emoji, non-Latin characters, and advanced escapes that depend on Unicode code points.

Without u, character handling can be surprising, especially when a single visible symbol is represented internally by multiple code units.

Same pattern, different result

Consider the pattern ^cat.$ against a multi-line string. Without flags, it only checks the entire input as one string and the dot will not cross line breaks. Add m and the anchors start working per line. Add s and the dot can now consume newline characters too.

This is why regex debugging is rarely just about the pattern itself. The matching mode matters just as much as the characters you typed.

Common mistakes

Many developers enable g when they really need m, or expect . to cross line breaks without s. Another common mistake is forgetting i when testing mixed-case input.

If the result looks inconsistent, test the exact same pattern with flags toggled one by one. That isolates whether the bug is in the expression or in the matching mode.

Debug it with the Regex Tester

Use the Regex Tester to toggle flags interactively and see how the same input changes under different modifiers. That is the fastest way to understand whether your regex logic is wrong or whether the right flag is simply missing.

Read on pigia.dev

Regex vs Wildcard Matching: When They Are Not Interchangeable

Sat, 21 Mar 2026 00:00:00 GMT

Comparison

Regex vs Wildcard Matching: When They Are Not Interchangeable

Learn when wildcard patterns are enough, when regex becomes necessary, and why switching between them causes matching bugs in tools, globs, and application code.

Quick answer

Wildcards are simpler and better for file globs or basic pattern filters.
Regex is better when you need anchors, capture groups, alternation, or validation rules.
They look similar in places, but they are not interchangeable syntax.

Why developers mix them up

Both regex and wildcard patterns let you describe text flexibly, so it is easy to assume they are two spellings of the same idea. They are not. A wildcard like *.json is designed for a narrow matching model, while regex supports a much richer language with anchors, quantifiers, grouping, and alternation.

This confusion shows up in file globs, ignore rules, route matching, validation code, and search filters. A pattern that looks plausible in one system can fail completely in another because the engine is different.

Where wildcards work better

Wildcards are ideal when you just need “anything here” or “any extension like this.” File paths, include/exclude lists, and simple product filters are good fits because the syntax is short and easier for non-specialists to read.

If the matching job is simple, wildcard syntax is often the better tool because it is easier to maintain and less error-prone.

Where regex becomes necessary

Regex matters when structure matters. If you need to validate a UUID, extract a query parameter from free-form text, anchor a pattern to the start of a line, or capture one part of the match for later use, wildcard syntax is not enough.

This is where developers graduate from “contains something like this” to “matches this exact structure.”

Common translation mistakes

People often paste *.json into a regex engine and wonder why it breaks. In regex, the dot means “any character” and the star repeats the previous token. The equivalent intent is closer to .*\.json$.

The reverse mistake happens too: using regex-only syntax like \d+ inside a wildcard matcher where it has no special meaning.

How to debug the difference

First confirm which matching system your tool actually uses. Then test a real sample string instead of reasoning from memory. The Regex Tester helps when the environment really is regex-based, and the fastest fix is often realizing that the original pattern language was wrong for the job.

Read on pigia.dev

Common Regex Mistakes With Escaping and Greediness

Sat, 21 Mar 2026 00:00:00 GMT

Guide

Common Regex Mistakes With Escaping and Greediness

See why regexes fail because of missing escapes, overly greedy quantifiers, and assumptions about line boundaries, plus how to debug those mistakes faster.

Escaping is context-sensitive

Regex escaping breaks down when developers remember the regex rules but forget the string-literal rules around them. For example, a JavaScript string may require \\d where a regex literal only needs \d.

This is why a pattern copied from documentation can fail after you paste it into code. The pattern is not always wrong. The surrounding syntax may be changing what the engine actually receives.

Greedy quantifiers grab more than you expect

Patterns like .* are greedy by default, which means they keep consuming text as long as the overall expression can still succeed. That often causes an extraction regex to swallow too much input, especially with HTML-like text, logs, or nested delimiters.

Switching to a non-greedy quantifier like .*? can fix the behavior, but only if the surrounding boundaries are correct too.

Anchors and flags change the result

Another common mistake is assuming ^ and $ work per line when multiline mode is not enabled. Similarly, developers expect a dot to cross newlines even though it will not without the right flag in many regex engines.

These bugs feel like escaping bugs because the pattern looks right on the surface, but the matching mode is really the issue.

Debugging approach

Reduce the pattern to the smallest failing example. Test against the exact text that fails in production. Then add escapes, boundaries, and flags back one at a time so you can see what changed the result.

The Regex Tester is useful here because it shows matches immediately and makes flag changes obvious.

Read on pigia.dev

SQL Formatting Conventions That Make Reviews Easier

Sat, 21 Mar 2026 00:00:00 GMT

Guide

SQL Formatting Conventions That Make Reviews Easier

Learn practical SQL formatting conventions that make joins, filters, and grouping logic easier to review and debug in code review and incident response.

Why formatting matters beyond aesthetics

SQL formatting is not just about making queries look tidy. It changes how quickly reviewers can spot bad joins, missing filters, duplicated conditions, and grouping mistakes. That makes formatting a debugging aid, not only a style preference.

Useful conventions in practice

Keep one major clause per line, align selected columns vertically, and place joins and join predicates where they are easy to scan. Long boolean conditions are easier to review when each predicate has its own line instead of disappearing inside a paragraph-shaped WHERE clause.

Consistency matters more than any one exact style. The point is to make query structure visible at a glance.

What formatting helps you catch

Readable spacing makes it easier to see when a LEFT JOIN was accidentally turned into an INNER JOIN by a filter, when aggregates are missing a GROUP BY field, or when a condition belongs in ON instead of WHERE.

Those are logic bugs, but formatting is often what makes them visible.

Use the formatter before debugging

Before you rewrite a suspicious query, pass it through the SQL Formatter. A cleaned-up version often reveals the actual problem immediately.

Read on pigia.dev

Common SQL Mistakes in Joins and Grouping

Sat, 21 Mar 2026 00:00:00 GMT

Guide

Common SQL Mistakes in Joins and Grouping

See the SQL mistakes that make results explode, disappear, or miscount, especially around joins, grouping, aggregates, and misplaced filters.

Joins multiply mistakes fast

A query can look valid and still be logically wrong because the join condition is too loose, the wrong join type is used, or a later filter removes the rows you thought you preserved. That leads to duplicated rows, missing results, or counts that do not reconcile.

Grouping hides problems until the numbers look wrong

Grouping bugs often appear as totals that are “close but off.” A missing dimension in GROUP BY, an aggregate over already-duplicated join results, or a non-aggregated column that should not be selected can all distort the result set.

Readable structure helps debugging

Formatting makes it easier to compare selected columns, join conditions, and aggregation logic line by line. When the query is flattened, these mistakes are much harder to see.

Start with a formatter

Before changing query logic, run the statement through the SQL Formatter. Separating clauses clearly is often enough to reveal why the result set changed.

Read on pigia.dev

HEX vs RGB vs HSL: Which Color Format Is Easier to Work With?

Sat, 21 Mar 2026 00:00:00 GMT

Comparison

HEX vs RGB vs HSL: Which Color Format Is Easier to Work With?

Compare HEX, RGB, and HSL for design systems, browser debugging, and developer workflows. Learn which format is easiest for editing, theming, and conversion.

Quick answer

HEX is compact and common in design handoff and CSS snippets.
RGB is useful when you think in channels or need alpha-friendly workflows.
HSL is often easier when you want to reason about hue, saturation, and lightness directly.

Quick answer

Start with the token if the claims look suspicious.
Check timestamps next if the auth bug smells time-based.
Parse raw headers when you are not sure what the request actually sent.

Where auth debugging usually starts

JWT-related failures often involve more than one layer. The token payload may be wrong, the signing setup may be different from what the application expects, the expiry window may be off, or the Authorization header may not be arriving the way you think it is.

That is why auth debugging works better as a workflow than as a single tool. You usually move from token generation to claim inspection to timestamp validation to raw header inspection in one session.

Recommended workflow

Generate a sample token with the JWT Generator when you need a controlled input. Inspect the result in the JWT Decoder. If the issue involves exp, iat, or nbf, verify the exact values in the Timestamp Converter. If the bug is still unclear, parse the request with the HTTP Header Parser to confirm the Authorization header and related metadata.

Most common auth failure patterns

Where clock skew causes damage

If the issuer and verifier clocks are not aligned, the same token can be rejected as expired or not-yet-valid even though the payload looks right. This is especially common in distributed systems, local development, and preview environments.

Helpful local workflow

Generate a test token with controlled timestamps in the JWT Generator, inspect the claims, and compare the converted values before changing application logic.

Read on pigia.dev

Why Callback and Redirect URLs Break in Real Apps

Sun, 22 Mar 2026 00:00:00 GMT

Guide

Why Callback and Redirect URLs Break in Real Apps

A troubleshooting guide for redirect and callback URL bugs involving nested encoding, wrong hosts, missing paths, and unexpected fragments.

Quick answer

Parse the full URL before editing anything.
Treat nested URLs inside query values as a separate encoding problem.
One unescaped character can shift the meaning of the whole query string.

Why malformed JSON wastes time

JSON errors are often tiny syntax mistakes hiding inside large payloads. One missing quote, one trailing comma, or one broken escape can make the whole document unreadable.

What to check first

Start with the JSON Formatter so the payload is validated and indented. Most malformed documents become easier to fix once the parser points to the failing region and the structure is visible.

Common failure patterns

Typical mistakes include using single quotes, leaving trailing commas, breaking string escaping, mixing objects and arrays incorrectly, and pasting partial payloads with missing braces.

When conversion should wait

If the payload is malformed, do not move straight into export or transformation. Validate the JSON first. Only then should you use tools like JSON to CSV Converter.

Read on pigia.dev

pigia.dev — Guides & Developer Resources

How JWT Decoding Differs From JWT Verification

How JWT Decoding Differs From JWT Verification

Quick answer

What decoding gives you

What verification adds

Common debugging traps

Useful local tooling

JSON vs XML: Which Format Should You Use?

JSON vs XML: Which Format Should You Use?

Quick answer

Where JSON is stronger

Where XML is still the better choice

What developers usually need in practice

Unix Timestamp Seconds vs Milliseconds

Unix Timestamp Seconds vs Milliseconds

The shortcut

Why this happens

How to sanity-check a suspicious value

Safe workflow

When Base64 Is Useful and When It Is Not

When Base64 Is Useful and When It Is Not

Good use cases

What Base64 does not do

Where teams get confused

Practical tooling

UUID vs GUID: Differences That Matter in Practice

UUID vs GUID: Differences That Matter in Practice

The practical answer

Where confusion shows up

Version matters more than the label

Generate the format you need

How Query Strings Handle Spaces, Arrays, and Duplicate Keys

How Query Strings Handle Spaces, Arrays, and Duplicate Keys

Spaces and special characters

Duplicate keys and arrays

Nested redirect URLs

Debugging workflow

When JSON to CSV Conversion Breaks Down

When JSON to CSV Conversion Breaks Down

Where conversion works well

Where it gets messy

How to decide before converting

Practical workflow

Regex Flags Explained: What g, i, m, s, and u Actually Do

Regex Flags Explained: What g, i, m, s, and u Actually Do

Quick answer

What regex flags do

The global flag: g

The case-insensitive flag: i

The multiline flag: m

The dotAll flag: s

The Unicode flag: u

Same pattern, different result

Common mistakes

Debug it with the Regex Tester

Regex vs Wildcard Matching: When They Are Not Interchangeable

Regex vs Wildcard Matching: When They Are Not Interchangeable

Quick answer

Why developers mix them up

Where wildcards work better

Where regex becomes necessary

Common translation mistakes

How to debug the difference

Common Regex Mistakes With Escaping and Greediness

Common Regex Mistakes With Escaping and Greediness

Escaping is context-sensitive

Greedy quantifiers grab more than you expect

Anchors and flags change the result

Debugging approach

SQL Formatting Conventions That Make Reviews Easier

SQL Formatting Conventions That Make Reviews Easier

Why formatting matters beyond aesthetics

Useful conventions in practice

What formatting helps you catch

Use the formatter before debugging

Common SQL Mistakes in Joins and Grouping

Common SQL Mistakes in Joins and Grouping

Joins multiply mistakes fast

Grouping hides problems until the numbers look wrong

The global flag: `g`

The case-insensitive flag: `i`

The multiline flag: `m`

The dotAll flag: `s`

The Unicode flag: `u`