DEV Community: kingfujing

REST vs GraphQL: Which API Style Should You Use in 2026?

kingfujing — Fri, 04 Sep 2026 11:29:50 +0000

Originally published on DevToolsHub — free, privacy-first developer tools that run entirely in your browser.

REST and GraphQL are the two dominant ways to design a web API today, and the debate between them is still alive — for good reason. They embody different philosophies: REST organizes an API around resources and HTTP semantics, while GraphQL organizes it around a typed schema and client-specified queries.

In this guide, we'll compare them across data fetching, caching, versioning, and real-world performance — so you can pick the right style for your next project instead of just following the hype.

💡 Quick Try: Both styles return JSON. Paste any API response into the free DevToolsHub JSON Formatter to inspect it with syntax highlighting and validation.

What is REST?

REST (Representational State Transfer) is an architectural style formalized by Roy Fielding in 2000. A RESTful API exposes resources as URLs, manipulates them with HTTP verbs (GET, POST, PUT, DELETE), and communicates outcomes through status codes (200, 201, 404, 429...). There is no single spec to implement — HTTP itself is the protocol, and conventions do the rest.

GET    /users/42          → 200 OK (one user)
GET    /users/42/posts    → 200 OK (their posts)
POST   /users             → 201 Created
DELETE /users/42          → 204 No Content

Pros: Simple and universally understood. HTTP caching (ETags, Cache-Control, CDNs) works out of the box. Status codes carry meaning. Any client, from curl to a smart fridge, can consume it.

Cons: Clients often need multiple round trips to assemble one view (under-fetching) or receive more data than they need (over-fetching). Endpoint sprawl grows with every new screen, and versioning (v1, v2...) becomes a maintenance burden.

What is GraphQL?

GraphQL is a query language for APIs and a runtime for executing those queries, open-sourced by Facebook in 2015 and now governed by the GraphQL Foundation. Instead of many endpoints, there is one endpoint and one strongly-typed schema. The client asks for exactly the fields it needs — in the exact shape it wants — and the server resolves them.

# One request: user + their posts, precisely shaped
query {
  user(id: 42) {
    name
    posts(last: 5) {
      title
      commentsCount
    }
  }
}

Pros: No over-fetching — the response mirrors the query. One round trip for nested data. A self-documenting type system with introspection (GraphiQL, generated SDKs). Frontend teams ship features without waiting for new endpoints.

Cons: HTTP-level caching largely disappears (everything is a POST to one URL). Resolver complexity can hide N+1 database queries. Query depth and cost must be limited to prevent abuse. More server-side machinery and a real learning curve.

Head-to-Head Comparison

Feature	REST	GraphQL
Type	✅ Architectural style	✅ Query language + runtime
Endpoints	Many (per resource)	One
Data shape	⚠️ Fixed by server	✅ Chosen by client
Over-fetching	❌ Common	✅ Eliminated
HTTP caching / CDN	✅ Native	❌ Needs custom layers
Versioning	⚠️ URL/header versions	✅ Schema evolution + deprecation
Learning curve	✅ Low	❌ Moderate to high

The Real Story: Trade-offs in Production

GraphQL was born from a concrete pain: Facebook's mobile news feed needed a deeply nested view of stories, authors, likes, and comments. With REST, that meant either a bespoke aggregation endpoint per screen or a waterfall of small requests over slow mobile networks. GraphQL flipped the contract — the client declares the view, the server composes it. For product teams iterating on UI weekly, that flexibility is the real selling point, not the absence of over-fetching alone.

But the costs are equally concrete. Because GraphQL requests are typically POSTs to a single URL, you lose HTTP caching almost entirely — no more free CDN caching of GET responses; caching moves into client libraries (Apollo, Relay) and custom server layers. And the resolver model introduces the classic N+1 problem: a list of 50 users can trigger 50 separate database lookups unless you batch with a tool like DataLoader. REST avoids this by design because each endpoint is a single handler you profile once.

The mature take in 2026: most serious platforms run both — REST for public, cache-heavy, resource-shaped APIs; GraphQL as an internal BFF (backend-for-frontend) layer where the client shape flexibility pays off.

When to Use Each

Use REST when:

You're building a public API for third-party developers
Responses are cacheable and CDN/HTTP caching matters
The domain is resource-shaped (CRUD on clear entities)
You need file uploads/downloads or streaming
The team wants standard tooling and a low learning curve

Use GraphQL when:

Clients are mobile or bandwidth-sensitive and over-fetching hurts
Screens need nested, aggregated data from many services
The frontend iterates fast and endpoint sprawl is slowing you down
You're unifying microservices behind a graph/federation layer
Multiple clients need different views of the same data

Code Examples

Node.js / Express: A REST endpoint

import express from 'express';
const app = express();

app.get('/api/users/:id', async (req, res) => {
  const user = await db.users.findById(req.params.id);
  if (!user) return res.status(404).json({ error: 'User not found' });
  res.set('Cache-Control', 'public, max-age=60'); // HTTP caching, free
  res.json(user);
});

app.listen(3000);

Apollo Server: The same data as GraphQL

import { ApolloServer } from '@apollo/server';
import { startStandaloneServer } from '@apollo/server/standalone';

const typeDefs = `
  type Post { title: String! }
  type User { name: String! posts: [Post!]! }
  type Query { user(id: ID!): User }
`;

const resolvers = {
  Query: {
    user: (_, { id }) => db.users.findById(id),
  },
  User: {
    posts: (user) => db.posts.findByUserId(user.id),
  },
};

const server = new ApolloServer({ typeDefs, resolvers });
await startStandaloneServer(server, { listen: { port: 4000 } });

Notice the difference: REST returns one fixed shape per URL; GraphQL lets the client compose user and posts in one request — at the price of managing a schema and resolvers on the server.

Final Verdict

🎯 Recommendation: Neither one "wins" — they solve different problems. Choose REST when your API is resource-shaped, benefits from HTTP caching, or is consumed by third parties. Choose GraphQL when client flexibility, nested views, and rapid frontend iteration are worth the extra server complexity. For most growing products: REST for the public edge, GraphQL as the internal BFF — the pragmatic hybrid.

Working with either style, you'll live in JSON responses — format and validate them in your browser with the free DevToolsHub JSON Formatter, no uploads required.

Common Mistakes & How to Avoid Them

Using GraphQL as a database. It's an API layer, not a query engine. Resolvers still execute database queries — a naive schema can generate worse queries than a hand-written REST handler.
Ignoring the N+1 problem. A list resolver that runs one query per item will melt your database under load. Batch with DataLoader or equivalent from day one.
Shipping GraphQL without depth limits. A malicious client can ask for infinitely nested queries and take your server down. Add depth limiting, cost analysis, or persisted queries.
Versioning GraphQL like REST. There is no v2 in GraphQL — evolve the schema: add fields, mark old ones @deprecated, and remove them only after usage monitoring shows they're gone.
Caching REST at the wrong level. If your REST responses vary by auth token, don't mark them publicly cacheable — you'll leak one user's data to another. Cache public resources; use ETags for the rest.

FAQ

Is GraphQL replacing REST?

No. REST remains the default for public APIs, simple resource operations, and anything that benefits from HTTP caching. GraphQL thrives in specific niches: mobile clients, aggregated views, and fast-moving frontend teams. Most large platforms run both.

Is GraphQL faster than REST?

It depends. GraphQL saves round trips for nested data (fewer network hops), but adds resolver overhead and loses HTTP caching. For a simple, cacheable resource, a well-designed REST endpoint served from a CDN is often faster end to end.

Can I use REST and GraphQL together?

Yes — and it's the most common architecture at scale. Expose a public REST API, and run an internal GraphQL BFF (backend-for-frontend) that aggregates your services for the app teams.

Does GraphQL only work over HTTP POST?

Queries and mutations are typically sent as HTTP POST to a single endpoint (GET is possible for queries but rare). Subscriptions use WebSocket or Server-Sent Events instead of plain HTTP.

How does caching work in GraphQL?

HTTP caching doesn't apply naturally because everything is a POST. Caching moves to normalized client-side stores (Apollo Client, Relay) and custom server layers like response caching or APQ (Automatic Persisted Queries).

Related Tools: JSON Formatter · URL Encoder / Decoder · JWT Decoder

If you found this useful, check out DevToolsHub — 9 free privacy-first developer tools, everything runs locally in your browser.

JWT vs OAuth2: What's the Difference and When to Use Each?

kingfujing — Tue, 25 Aug 2026 11:39:26 +0000

Originally published on DevToolsHub — free, privacy-first online tools for developers.

JWT and OAuth2 are two of the most confused terms in modern web development. Many developers treat them as interchangeable — but they solve completely different problems. JWT is a token format, while OAuth2 is an authorization framework. They often work together, which is exactly why the confusion exists.

In this guide, we'll compare JWT and OAuth2 across their roles, use cases, and how they combine — so you know what you're actually implementing in your next project.

💡 Quick Try: Have a token to inspect? Use our free JWT Decoder to decode and verify tokens right in your browser.

What is JWT?

JWT (JSON Web Token) is a compact, self-contained token format defined by RFC 7519. It's a JSON object encoded as a string, containing claims like user ID, role, and expiry, signed with a secret or public key. Anyone with the signing key can verify the token's authenticity without contacting a server.

header.payload.signature

// header: {"alg":"HS256","typ":"JWT"}
// payload: {"sub":"123","role":"admin","exp":1700000000}
// signature: HMACSHA256(base64Url(header)+"."+base64Url(payload), secret)

Pros: Self-contained — carries claims without a lookup. Verifiable offline. Works across any service that shares the key.

Cons: Just a token format — doesn't define how to get, refresh, or revoke it. No built-in scopes or third-party flow.

What is OAuth2?

OAuth2 is an authorization framework (RFC 6749) that defines how a user can grant a third-party application limited access to their resources. It involves roles (resource owner, client, authorization server, resource server), flows (authorization code, client credentials, PKCE), and scopes that limit what the token can do.

OAuth2 roles:
┌─────────────┐      ┌──────────────────┐
│  User (RO)  │      │ Client (App)     │
└──────┬──────┘      └────────┬─────────┘
       │                      │
       ▼                      ▼
┌─────────────────────────────────────┐
│  Authorization Server (e.g. Google) │
│  Issues access tokens + scopes      │
└─────────────────────────────────────┘

Pros: Standardized flows for third-party login. Scopes limit permissions. Industry standard for "Sign in with Google/GitHub".

Cons: Complex — multiple flows, redirects, and endpoints to manage. Tokens themselves can be any format (often JWT, but not required).

Head-to-Head Comparison

Feature	JWT	OAuth2
Type	✅ Token format	✅ Authorization framework
Solves	How to encode claims	How to grant access
Authentication	✅ Can carry auth data	❌ Authorization only
Scopes	❌ Not built-in	✅ First-class
Third-party login	❌ Not defined	✅ Core use case
Refresh flow	❌ Your job	✅ Standardized
Token format	✅ JWT (always)	⚠️ Opaque or JWT

How They Work Together: The Real Story

The confusion comes from the fact that OAuth2 often uses JWT as its access token format. When you sign in with Google, Google's authorization server issues an access token — and that token is frequently a JWT. So you're using both: OAuth2 for the flow, JWT for the token.

A common implementation: OAuth2 Authorization Code flow with PKCE obtains a JWT access token. The resource server verifies the JWT signature offline (no database lookup), while the authorization server handles issuing, refreshing, and revoking through OAuth2 endpoints.

JWT alone — fine for first-party apps (your SPA talking to your API)
OAuth2 alone — possible with opaque tokens (server validates via introspection)
OAuth2 + JWT — the industry standard for third-party access

When to Use Each

Use JWT when:

You need a self-contained, verifiable token for your own API
You want stateless auth across microservices sharing a key
You're building a first-party SPA/mobile app with your own login
You need to embed claims (role, permissions) in the token itself

Use OAuth2 when:

You need "Sign in with Google/GitHub/Facebook" third-party login
A third-party app needs limited access to your users' resources
You need scopes to control what each token can do
You're building an API platform that other developers integrate

Code Examples

Node.js: Sign-in with Google (OAuth2 + JWT)

const { OAuth2Client } = require('google-auth-library');
const jwt = require('jsonwebtoken');

const client = new OAuth2Client(GOOGLE_CLIENT_ID);

// Frontend sends the Google ID token after OAuth2 flow
async function googleLogin(idToken) {
  // 1. Verify the Google-issued token (OAuth2 flow result)
  const ticket = await client.verifyIdToken({
    idToken,
    audience: GOOGLE_CLIENT_ID
  });
  const { email, name } = ticket.getPayload();

  // 2. Issue your own JWT for your API
  const appToken = jwt.sign({ email, name }, JWT_SECRET, { expiresIn: '1h' });
  return appToken;
}

Python / FastAPI: JWT-only auth (first-party)

import jwt
from fastapi import Depends, HTTPException
from fastapi.security import OAuth2PasswordBearer

# OAuth2PasswordBearer is just a token extractor — the token itself is a JWT
oauth2_scheme = OAuth2PasswordBearer(tokenUrl="/login")

def get_current_user(token: str = Depends(oauth2_scheme)):
    try:
        payload = jwt.decode(token, SECRET, algorithms=["HS256"])
        return payload["sub"]
    except jwt.PyJWTError:
        raise HTTPException(status_code=401, detail="Invalid token")

Final Verdict

🎯 Recommendation: They're not competitors — they're complementary. Use OAuth2 when you need standardized third-party login or scoped access to resources. Use JWT as the token format for fast, stateless verification. For most production apps: OAuth2 for the flow, JWT for the token — best of both worlds.

Decode and inspect any JWT instantly with our free online JWT Decoder. It runs entirely in your browser — no server uploads, no data leaks.

Common Mistakes & How to Avoid Them

Calling OAuth2 an authentication protocol. OAuth2 is about authorization (what you can access). For identity, pair it with OIDC (OpenID Connect) which adds an ID token.
Assuming OAuth2 requires JWT. OAuth2 tokens can be opaque strings validated via server introspection. JWT is optional — though very common.
Using JWT for third-party login. JWT alone has no flow for redirecting users to Google. You need OAuth2 (or OIDC) for the dance, JWT for the ticket.
Ignoring scopes. If you hand out full-access tokens, you've missed the point of OAuth2. Always request the minimum scopes needed.
Reinventing the wheel. Don't build your own OAuth2 server unless you must. Use Auth0, Keycloak, or the identity provider's managed flow.

Frequently Asked Questions

Is JWT the same as OAuth2?

No. JWT is a token format (how claims are encoded), while OAuth2 is an authorization framework (how access is granted). OAuth2 commonly uses JWT as its token format, but they are distinct concepts.

Does OAuth2 use JWT tokens?

Often yes, but not required. Many identity providers (Google, Auth0) issue JWT access tokens, but OAuth2 also supports opaque tokens validated via the introspection endpoint. JWT is the popular choice for stateless verification.

Should I use JWT or OAuth2 for my app?

For a first-party app with your own login, JWT alone is usually enough. For third-party login (Sign in with Google/GitHub) or building an API for other developers, use OAuth2 — with JWT as the token format.

What is the difference between OAuth2 and OIDC?

OAuth2 handles authorization (access tokens, scopes). OIDC (OpenID Connect) builds on OAuth2 and adds an ID token for authentication — so you know who the user is, not just what they can access.

Can I use JWT without OAuth2?

Absolutely. JWT is a standalone standard. You can issue and verify JWTs with your own login endpoint, no OAuth2 involved. OAuth2 only becomes necessary when you need third-party flows or scoped delegation.

SQL vs NoSQL: Which Database Should You Choose in 2026?

kingfujing — Tue, 25 Aug 2026 11:39:20 +0000

Originally published on DevToolsHub — free, privacy-first online tools for developers.

Choosing a database is one of the most consequential decisions in software architecture. SQL (PostgreSQL, MySQL) has ruled for 40+ years with rock-solid transactions. NoSQL (MongoDB, Redis, Cassandra) powers modern web scale with flexible schemas. But "SQL vs NoSQL" is not a one-size-fits-all battle — the right answer depends on your data, your scale, and your consistency requirements.

In this guide, we'll compare SQL and NoSQL across schema flexibility, scalability, transactions, and query power — so you can make an informed choice for your next project.

💡 Quick Try: Working with JSON data from your database? Use our free JSON Formatter to beautify and validate it right in your browser.

What is SQL (Relational)?

SQL databases organize data into tables with fixed schemas — rows and columns connected by relationships (foreign keys). They guarantee ACID transactions (Atomicity, Consistency, Isolation, Durability), which makes them the default choice for anything involving money, orders, or critical business data.

-- Fixed schema: every row has all columns
CREATE TABLE users (
  id SERIAL PRIMARY KEY,
  email VARCHAR(255) UNIQUE NOT NULL,
  name VARCHAR(100),
  created_at TIMESTAMPTZ DEFAULT now()
);

-- Powerful joins across related tables
SELECT u.name, o.total
FROM users u
JOIN orders o ON o.user_id = u.id
WHERE o.status = 'paid';

Pros: ACID transactions. Mature ecosystem and tooling. Complex queries with JOINs. Enforced data integrity.

Cons: Rigid schema — migrations are work. Vertical scaling is expensive. Sharding across nodes is complex.

What is NoSQL (Non-Relational)?

NoSQL is an umbrella term for databases that don't use the relational model. Common types: document (MongoDB), key-value (Redis), column-family (Cassandra), and graph (Neo4j). They trade strict consistency for flexibility and horizontal scalability — schemas are flexible, and data scales across many cheap nodes.

// Document store: schema-less, embed related data
{
  "_id": "507f1f77bcf86cd799439011",
  "email": "alice@example.com",
  "name": "Alice",
  "orders": [
    { "id": 1, "total": 99.5, "status": "paid" }
  ]  // related data embedded, no JOIN needed
}

Pros: Flexible schema — iterate fast. Horizontal scaling via sharding. Great for high write throughput and unstructured data.

Cons: No ACID guarantees (mostly). Complex queries require denormalization or aggregation pipelines. Consistency is often eventual.

Head-to-Head Comparison

Feature	SQL	NoSQL
Schema	✅ Fixed, enforced	❌ Flexible, dynamic
Transactions	✅ ACID	⚠️ Limited / eventual
Scaling	⚠️ Vertical (expensive)	✅ Horizontal (sharding)
Queries	✅ Powerful JOINs	⚠️ Limited relations
Flexibility	❌ Migrations needed	✅ Iterate instantly
Maturity	✅ 40+ years	⚠️ 15+ years
Best for	Money, orders, integrity	Scale, flexibility, speed

Scaling and Consistency: The Real Story

The biggest divide is the CAP theorem. SQL databases prioritize consistency — every read sees the latest write. NoSQL databases often prioritize availability and partition tolerance, accepting eventual consistency (reads may briefly see stale data).

In practice: a banking ledger must be consistent (SQL). A social media feed can tolerate a few seconds of staleness for the benefit of scaling to millions of users (NoSQL). Modern databases blur the line — PostgreSQL supports JSON columns for flexibility, and MongoDB added multi-document transactions — but the core tradeoff remains.

When to Use Each

Use SQL when:

Data has clear relationships (users → orders → items)
You need ACID transactions (payments, inventory, bookings)
You need complex queries with JOINs and aggregations
Data integrity is non-negotiable (finance, healthcare)

Use NoSQL when:

You have unstructured or rapidly changing data shapes
You need to scale horizontally to millions of users/writes
You're building real-time, high-throughput systems (caching, events)
Your queries are simple lookups, not complex joins

Code Examples

PostgreSQL: Relational with JSONB (hybrid)

-- Best of both: relational integrity + flexible JSON
CREATE TABLE products (
  id SERIAL PRIMARY KEY,
  name TEXT NOT NULL,
  price NUMERIC(10,2),
  attributes JSONB  -- flexible metadata
);

-- Query inside JSON
SELECT name FROM products
WHERE attributes->>'color' = 'red';

MongoDB: Document model

// Embedded documents avoid expensive joins
db.orders.insertOne({
  userId: ObjectId("..."),
  items: [
    { sku: "A1", qty: 2, price: 29.99 },
    { sku: "B2", qty: 1, price: 9.99 }
  ],
  total: 69.97,
  status: "pending"
});

// Flexible query with aggregation pipeline
db.orders.aggregate([
  { $match: { status: "paid" } },
  { $group: { _id: "$userId", total: { $sum: "$total" } } }
]);

Redis: Key-value cache

// Lightning-fast reads for hot data
SET session:user:1001 "{ \"name\": \"Alice\", \"role\": \"admin\" }"
EXPIRE session:user:1001 3600

// Rate limiting with atomic increment
INCR rate:api:user-1001
EXPIRE rate:api:user-1001 60

Final Verdict

🎯 Recommendation: Start with SQL (PostgreSQL) unless you have a specific reason not to. It handles 95% of applications with ACID guarantees and a mature ecosystem. Reach for NoSQL when you hit real scale problems, need flexible schemas for unstructured data, or require high write throughput. Most production systems use both — SQL for canonical data, NoSQL for caching and hot paths.

Format and validate JSON from your database queries with our free online JSON Formatter. It runs entirely in your browser — no server uploads, no data leaks.

Common Mistakes & How to Avoid Them

Choosing NoSQL for the wrong reason. "MongoDB is trendy" is not a requirement. If you need JOINs and transactions, SQL will save you months of pain.
Ignoring schema migrations in SQL. Every schema change is work. Plan migrations with tools like Prisma or Flyway from day one.
Assuming NoSQL means no constraints. Flexible schema still needs validation — enforce it in your application layer or schema validation features (MongoDB validation rules).
Storing everything in one database. Use the right tool for each job: PostgreSQL for canonical data, Redis for cache, Elasticsearch for search.
Ignoring the CAP tradeoff. If your NoSQL system promises strong consistency, you're paying for it elsewhere — usually in availability or latency. Know your tradeoff.

Frequently Asked Questions

Is NoSQL faster than SQL?

Not inherently. NoSQL is often faster for simple lookups and high write throughput because it avoids JOINs and scales horizontally. But SQL with proper indexes is extremely fast too. The speed difference comes from workload design, not the database category.

Can I use SQL and NoSQL together?

Yes, this is a polyglot persistence pattern. Use SQL for canonical data with ACID guarantees, Redis for caching, and Elasticsearch for full-text search. Many production systems combine multiple databases per concern.

Is MongoDB better than PostgreSQL?

Neither is universally better. PostgreSQL wins for relational data, complex queries, and transactions. MongoDB wins for flexible schemas and horizontal scaling. Modern PostgreSQL even supports JSONB, closing much of the gap.

When should I switch from SQL to NoSQL?

Only switch when you hit concrete problems SQL can't solve: horizontal write scaling beyond a single node, unstructured data with rapidly evolving shapes, or very high throughput requirements. "We might need it someday" is not a good reason.

What is the best database for a new startup?

PostgreSQL. It's free, battle-tested, handles JSON (JSONB) for flexibility, scales to millions of rows, and won't become a bottleneck as you grow. Add Redis for caching and NoSQL only when your workload demands it.

JSON vs YAML: Which Data Format Should You Use?

kingfujing — Tue, 25 Aug 2026 11:38:36 +0000

Originally published on DevToolsHub — free, privacy-first online tools for developers.

JSON and YAML are the two most popular data formats for developers. JSON powers almost every web API, while YAML is the default for Docker Compose, Kubernetes, GitHub Actions, and Ansible. But they solve overlapping problems in different ways — and choosing wrong can make your config files painful to maintain.

In this guide, we'll compare JSON and YAML across readability, nesting, comments, anchors, and parse speed — so you can pick the right format for your next config file or API.

💡 Quick Try: Need to format or validate JSON? Use our free JSON Formatter right in your browser.

What is JSON?

JSON (JavaScript Object Notation) is a text-based data format that mirrors JavaScript object syntax. It uses curly braces, brackets, and key-value pairs, and it's the de-facto standard for web APIs — every language has a built-in JSON parser.

{
  "name": "DevToolsHub",
  "tools": ["json", "base64", "regex"],
  "free": true,
  "rating": 4.8
}

Pros: Universal parser support. Strict syntax with no ambiguity. Great for data interchange between systems.

Cons: Verbose (brackets everywhere). No comments in the official spec. Hard to hand-write for complex nested configs.

What is YAML?

YAML (YAML Ain't Markup Language) is a human-friendly data format that uses indentation instead of brackets. It's designed to be readable by humans at a glance, which makes it the default for configuration files across Docker, Kubernetes, and CI/CD pipelines.

# Server config
tools:
  - json
  - base64
  - regex
free: true
rating: 4.8

Pros: Clean, readable syntax with minimal noise. Supports comments. Has anchors (&) for reusing values. Native multi-line strings.

Cons: Indentation-sensitive — a space can break your config. No universal parser (Python, Ruby, JS vary). Type coercion surprises (e.g., yes becoming a boolean).

Head-to-Head Comparison

Feature	JSON	YAML
Readability	⚠️ Verbose brackets	✅ Clean indentation
Comments	❌ Not in spec	✅ Native support
Parse Speed	✅ Fast (native parsers)	❌ 3-10x slower
Parser Support	✅ Universal (built-in)	⚠️ Library needed
Reuse / Anchors	❌ None	✅ Anchors & aliases
Multi-line Strings	⚠️ Escaping hell	✅ Native (\|, >)
Type Safety	✅ Strict types	⚠️ Type coercion traps

Parse Speed: The Real Story

JSON parsers are natively built into every language and optimized at the C/Rust level — JSON.parse() handles millions of operations per second. YAML parsers are separate libraries and typically run 3-10x slower, because the spec is far more complex (anchors, tags, multi-document, type resolution).

For config files loaded once at startup, this difference is irrelevant. For high-frequency data interchange (APIs, event streams, message queues), JSON's speed advantage is decisive.

When to Use Each

Use JSON when:

You're building a web API or exchanging data between services
Performance matters — high-frequency parse/serialize cycles
You need universal compatibility across languages and tools
Your data has strict types (numbers vs strings must be unambiguous)

Use YAML when:

You're writing configuration files humans will edit (CI/CD, Docker, K8s)
You need comments to document config options
Your config has lots of repeated values (anchors save duplication)
You're defining complex nested structures that JSON would be unreadable

Converting Between JSON and YAML

Python: JSON → YAML

import json
import yaml

data = {"name": "DevToolsHub", "free": True, "tools": ["json", "base64"]}

# JSON string
json_str = json.dumps(data, ensure_ascii=False)

# YAML string
yaml_str = yaml.dump(data, default_flow_style=False)
print(yaml_str)
# name: DevToolsHub
# free: true
# tools:
#   - json
#   - base64

JavaScript: JSON → YAML (js-yaml)

const yaml = require('js-yaml');

const json = {
  name: 'DevToolsHub',
  free: true,
  tools: ['json', 'base64', 'regex']
};

const yamlStr = yaml.dump(json);
console.log(yamlStr);
// name: DevToolsHub
// free: true
// tools:
//   - json
//   - base64
//   - regex

Node.js: CLI one-liner

# JSON file to YAML on the command line
npx js-yaml config.json > config.yaml

# YAML file to JSON
npx js-yaml --json config.yaml > config.json

Final Verdict

🎯 Recommendation: For data interchange (APIs, storage, messaging), use JSON — it's faster, universal, and unambiguous. For human-authored configuration files, use YAML — comments, anchors, and readable indentation make it far easier to maintain. The two aren't rivals; they're tools for different jobs.

Format, validate, and beautify your JSON instantly with our free online JSON Formatter. It runs entirely in your browser — no server uploads, no data leaks.

Common Mistakes & How to Avoid Them

Using YAML for API payloads. YAML's parsing ambiguity (type coercion, indentation) makes it a bad fit for cross-system data. Use JSON for anything that leaves your process.
Trusting YAML's implicit typing. yes, no, on, off become booleans in many parsers. Quote values when in doubt.
Mixing tabs and spaces in YAML. YAML forbids tabs for indentation. Configure your editor to use spaces and it'll never bite you.
Adding comments to JSON. Not part of the spec — tools will reject them. If you need comments in a config, that's a signal to use YAML.
Hand-writing JSON for big configs. Nested objects with 5+ levels of brackets are error-prone. Write it in YAML and convert, or generate JSON programmatically.

Frequently Asked Questions

Is YAML a superset of JSON?

Yes — JSON is valid YAML 1.2, so you can embed JSON directly in a YAML file. But not all YAML is valid JSON, and YAML's additional features (anchors, tags, multi-document) don't exist in JSON.

Why does Kubernetes use YAML instead of JSON?

Because manifests are human-authored configuration files. YAML's comments, anchors, and readability make long Kubernetes manifests far more maintainable. Internally, Kubernetes converts YAML to JSON before processing.

Which is faster, JSON or YAML parsing?

JSON parsing is typically 3-10x faster than YAML because JSON has native built-in parsers and a much simpler spec. For config files loaded once this doesn't matter; for high-frequency APIs it's decisive.

Can I add comments to JSON files?

Not in the official spec — standard JSON parsers reject comments. Some tools support JSONC (JSON with Comments) or JSON5, but for maximum compatibility you should use YAML if you need comments.

Should I use YAML for my application config?

If humans maintain the config and you need comments — yes, YAML is the better choice. If the config is machine-generated or must be validated strictly, JSON is safer and more portable.

JWT vs Session: Which Authentication Method Should You Use?

kingfujing — Tue, 25 Aug 2026 11:38:35 +0000

Originally published on DevToolsHub — free, privacy-first online tools for developers.

Every web developer eventually hits the same fork in the road: should I use JWT tokens or server-side sessions for authentication? It's one of the most debated topics in backend development — and the answer depends on your architecture, scale, and security requirements.

In this guide, we'll compare JWT and session-based auth across scalability, security, CSRF protection, and real-world use cases — so you can pick the right approach for your next project.

💡 Quick Try: Have a token you want to inspect? Use our free JWT Decoder to decode and verify tokens right in your browser.

What is JWT (JSON Web Token)?

JWT is a stateless authentication mechanism. When a user logs in, the server signs a JSON token containing claims (user ID, role, expiry) and hands it to the client. The client sends the token in the Authorization header on every request. The server just verifies the signature — it doesn't need to store anything about the session.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOiIxMjM0NTYiLCJyb2xlIjoiYWRtaW4iLCJleHAiOjE3MDAwMDAwMDB9.3Z8Z0Z0Z0Z0Z0Z0Z0Z0Z0Z0Z0Z0Z0Z0Z0Z0

Pros: Stateless and horizontally scalable. Works perfectly for mobile apps, SPAs, and microservices. No server-side lookup needed.

Cons: Hard to revoke before expiry. Token size adds to every request. Secret management is critical — a leaked signing key compromises everything.

What is Session-Based Authentication?

Sessions are stateful. The server stores session data (usually in memory, Redis, or a database) and hands the client a random opaque session ID — typically an HTTP-only cookie. On each request, the server looks up the session by ID.

// Session flow (simplified)
POST /login  →  { "sessionId": "a1b2c3d4..." } stored server-side
GET /profile  →  Cookie: sid=a1b2c3d4  →  server looks up session
// Logout  →  delete session → instantly invalid

Pros: Instant revocation (logout/ban works immediately). No sensitive data in the client. Smaller per-request payloads.

Cons: Stateful — horizontal scaling requires shared storage (Redis). Requires CSRF protection for cookies. Not ideal for cross-origin mobile APIs.

Head-to-Head Comparison

Feature	JWT	Session
State	✅ Stateless	❌ Stateful
Scalability	✅ Excellent (no shared store)	⚠️ Needs Redis/DB
Revocation	❌ Hard (until expiry)	✅ Instant (logout/ban)
CSRF Risk	✅ Low (header-based)	❌ High (cookies)
Payload Size	❌ Larger (token in each request)	✅ Tiny (just session ID)
Mobile / API	✅ Native fit	⚠️ Awkward (cookie handling)
Microservices	✅ Ideal	❌ Central store required

Security: The Real Story

The security comparison isn't as one-sided as it seems. JWT tokens live in localStorage are vulnerable to XSS — any injected script can read them. Sessions stored in HTTP-only cookies are immune to XSS but require CSRF protection.

XSS risk: JWT in localStorage → token theft. Session in HttpOnly cookie → safe.
CSRF risk: Session cookie → vulnerable (needs CSRF tokens). JWT in Authorization header → immune.
Token leakage: JWT appears in browser history/proxies if passed in URL — always use headers.

When to Use Each

Use JWT when:

You're building microservices or a distributed system
You need a stateless API for mobile apps or third-party clients
You want to avoid a shared session store (Redis) entirely
You need short-lived access tokens + refresh token flow

Use Session when:

You're building a traditional server-rendered web app
You need instant revocation (admin bans, account compromise)
You have a single server or already run Redis
You want the simplest secure default for a standard web app

Code Examples

Node.js / Express: JWT

const jwt = require('jsonwebtoken');

// Sign a token at login
const token = jwt.sign({ userId: 123, role: 'admin' }, process.env.JWT_SECRET, {
  expiresIn: '15m'
});

// Verify on every request (middleware)
function auth(req, res, next) {
  const token = req.headers.authorization?.split(' ')[1];
  try {
    req.user = jwt.verify(token, process.env.JWT_SECRET);
    next();
  } catch (e) {
    res.status(401).json({ error: 'Invalid token' });
  }
}

Node.js / Express: Session with Redis

const session = require('express-session');
const RedisStore = require('connect-redis')(session);
const redis = require('redis').createClient();

app.use(session({
  store: new RedisStore({ client: redis }),
  secret: process.env.SESSION_SECRET,
  cookie: { httpOnly: true, sameSite: 'strict', maxAge: 24*60*60*1000 },
  resave: false,
  saveUninitialized: false
}));

// Logout = instant revocation
app.post('/logout', (req, res) => {
  req.session.destroy();
  res.clearCookie('connect.sid');
  res.json({ ok: true });
});

Python / FastAPI: JWT

import jwt
from fastapi import Depends, HTTPException
from fastapi.security import HTTPBearer

security = HTTPBearer()

def verify_token(creds=Depends(security)):
    try:
        payload = jwt.decode(creds.credentials, SECRET, algorithms=["HS256"])
        return payload
    except jwt.PyJWTError:
        raise HTTPException(status_code=401, detail="Invalid token")

Final Verdict

🎯 Recommendation: For API-first applications, mobile backends, and microservices, start with JWT — the stateless design scales without a shared store. For traditional server-rendered web apps where you need instant revocation and the simplest secure default, stick with sessions. Many production systems use both: sessions for the web frontend, JWTs for the API.

Inspect and debug your tokens instantly with our free online JWT Decoder. It runs entirely in your browser — no server uploads, no data leaks.

Common Mistakes & How to Avoid Them

Storing JWTs in localStorage. XSS can steal them. Prefer short-lived tokens in memory or HTTP-only cookies (with CSRF protection).
Using a weak JWT secret. A brute-forceable secret means forged tokens. Use crypto.randomBytes(32).toString('hex').
No token expiry. Long-lived tokens that never expire are a security liability. Use 10-15 minute access tokens with a refresh token flow.
Not handling revocation. If you need to ban users instantly, sessions are simpler. For JWT, add a token blacklist or short expiry.
Ignoring CSRF with session cookies. Always add CSRF tokens or use SameSite=Strict cookies.

Frequently Asked Questions

Is JWT more secure than sessions?

Neither is inherently more secure — they have different threat models. JWT is vulnerable to XSS when stored in localStorage; sessions are vulnerable to CSRF when using cookies. Both are secure when implemented correctly.

Can I revoke a JWT token before it expires?

Not directly — JWTs are stateless by design. You can implement a token blacklist (Redis set of revoked jti values), use very short expiry with refresh tokens, or switch to sessions if instant revocation is a hard requirement.

Is JWT stateless really faster than sessions?

JWT skips the server-side lookup, but signature verification (HMAC or RSA) costs CPU. Sessions with Redis are often faster in practice for high-traffic apps because lookups are O(1) and tokens stay small.

Can I use JWT with cookies instead of localStorage?

Yes — storing the JWT in an HTTP-only cookie protects it from XSS. You still need CSRF protection, but this hybrid gives you stateless verification with cookie-grade XSS resistance.

Which is better for mobile apps, JWT or sessions?

JWT is the natural fit for mobile. Native apps handle the Authorization header cleanly, and you avoid cookie management entirely. Sessions work but require extra work for cookie storage and CSRF on mobile.

URL Encoding Decoded: A Developer's Guide to encodeURI vs encodeURIComponent

kingfujing — Mon, 13 Jul 2026 16:01:04 +0000

Originally published on DevToolsHub — free, privacy-first online tools for developers.

Every developer has seen it: %20, %3A, %2F — URL encoding is everywhere. Whether you're building REST APIs, handling form submissions, parsing query strings, or debugging OAuth redirects, understanding URL encoding is essential.

🔧 Try it yourself: Use the free URL Encoder / Decoder — supports both encodeURIComponent and encodeURI modes with instant bidirectional conversion. All processing happens in your browser — zero data leaves your machine.

What is URL Encoding?

URL encoding (also called percent-encoding) converts special characters into a format that can be safely transmitted in URLs. Only a limited set of characters are allowed unescaped in URLs: alphanumeric characters (A-Z, a-z, 0-9) and a few special characters like -, _, ., ~.

Everything else gets encoded as a % followed by two hexadecimal digits representing the character's UTF-8 byte value.

Character	Encoded	Why It's Encoded
Space	`%20`	Not allowed in URLs
`?`	`%3F`	Starts query string
`&`	`%26`	Separates query params
`=`	`%3D`	Key-value separator
`#`	`%23`	Starts fragment identifier
`/`	`%2F`	Path separator
`@`	`%40`	Mailto/auth separator
`中`	`%E4%B8%AD`	Non-ASCII character

The Two JavaScript Encoding Functions

JavaScript provides two built-in URL encoding functions — and choosing the wrong one is one of the most common bugs in web development.

`encodeURI()` — For Full URLs

encodeURI("https://example.com/search?q=hello world&lang=en")
// Result: "https://example.com/search?q=hello%20world&lang=en"

encodeURI() encodes special characters except those that have structural meaning in a URL (?, &, =, #, /). It assumes you're encoding a complete URL and preserves its structure.

Use when: you have a complete URL that contains characters needing encoding (like spaces in the path).

`encodeURIComponent()` — For Query Parameters

encodeURIComponent("hello world & more")
// Result: "hello%20world%20%26%20more"

encodeURIComponent("name=John & age=30")
// Result: "name%3DJohn%20%26%20age%3D30"

encodeURIComponent() encodes everything — including ?, &, =, #, and /. This is what you want when building query strings.

Use when: building query parameters, encoding user input for URLs, or handling data that needs to be embedded in a URL.

🔴 The Classic Bug

// ❌ WRONG — using encodeURI for query params
const name = "John & Jane";
const url = `https://api.example.com?name=${encodeURI(name)}`;
// Result: "https://api.example.com?name=John%20&%20Jane"
//                            The "&" was NOT encoded! ← BROKEN QUERY

// ✅ CORRECT — using encodeURIComponent for query params
const url = `https://api.example.com?name=${encodeURIComponent(name)}`;
// Result: "https://api.example.com?name=John%20%26%20Jane"
//                            Everything is encoded ✓

The Golden Rule: When building URL query strings, always use encodeURIComponent() for each parameter value. Never pass raw user input into a URL.

The Complete Character Reference

Here's what the two encoding modes leave untouched:

Character Group	`encodeURI()`	`encodeURIComponent()`
`A-Z`, `a-z`, `0-9`	✅ Preserved	✅ Preserved
`- _ . ~`	✅ Preserved	✅ Preserved
`! ' ( ) *`	✅ Preserved	✅ Preserved
`?`	✅ Preserved	❌ Encoded → `%3F`
`&`	✅ Preserved	❌ Encoded → `%26`
`=`	✅ Preserved	❌ Encoded → `%3D`
`#`	✅ Preserved	❌ Encoded → `%23`
`/`	✅ Preserved	❌ Encoded → `%2F`
Space	❌ Encoded → `%20`	❌ Encoded → `%20`
`@`	❌ Encoded → `%40`	❌ Encoded → `%40`
`:`	❌ Encoded → `%3A`	❌ Encoded → `%3A`

Real-World Scenarios

1. Building a Search URL

const baseUrl = "https://api.books.com/search";
const query = "JavaScript & CSS";
const category = "web dev";
const page = 1;

// ✅ Correct approach
const params = new URLSearchParams({
  q: query,
  cat: category,
  page: page.toString()
});

const url = `${baseUrl}?${params.toString()}`;
// "https://api.books.com/search?q=JavaScript+%26+CSS&cat=web+dev&page=1"

Pro tip: Use URLSearchParams instead of manual string concatenation — it handles encoding correctly for all browsers.

2. Decoding URLs from Server Logs

Raw log entry:
  GET /search?q=JavaScript+%26+CSS&referrer=https%3A%2F%2Fgoogle.com

After decoding:
  Path: /search
  q: JavaScript & CSS
  referrer: https://google.com

3. Handling Unicode and Emoji

encodeURIComponent("你好世界")
// Result: "%E4%BD%A0%E5%A5%BD%E4%B8%96%E7%95%8C"

encodeURIComponent("🔥 🚀")
// Result: "%F0%9F%94%A5%20%F0%9F%9A%80"

// ✅ Decoding is symmetrical
decodeURIComponent("%E4%BD%A0%E5%A5%BD")
// Result: "你好"

4. OAuth Redirect URLs

OAuth flows often require encoding the redirect_uri parameter:

const redirectUri = "https://myapp.com/callback?source=email&plan=premium";
const encoded = encodeURIComponent(redirectUri);
// "https%3A%2F%2Fmyapp.com%2Fcallback%3Fsource%3Demail%26plan%3Dpremium"

const oauthUrl = `https://auth.provider.com/authorize?redirect_uri=${encoded}&client_id=abc123`;

Common Pitfalls

Pitfall 1: Double Encoding

const input = "hello%20world";

// 🔴 Double encoding — the %25 will be treated as a literal percent
const bad = encodeURIComponent(input);
// Result: "hello%2520world"
//                 ^^ This is "%25" followed by "20", NOT a space!

// ✅ Correct — only encode once
const good = input; // Already encoded, or use decodeURIComponent first

Pitfall 2: Forgetting to Decode on the Backend

Most web frameworks handle URL decoding automatically (Express, Flask, Spring Boot all do). But if you're building a custom URL parser, remember to call decodeURIComponent().

Pitfall 3: The `+` vs `%20` Confusion

Application/x-www-form-urlencoded forms encode spaces as +. But URL encoding (percent-encoding) uses %20. JavaScript's encodeURIComponent() uses %20, not +. URLSearchParams uses +. Both work — just be consistent.

Language Quick Reference

Language	Encode	Decode
JavaScript	`encodeURIComponent(str)`	`decodeURIComponent(str)`
Python	`urllib.parse.quote(str)`	`urllib.parse.unquote(str)`
Python (query)	`urllib.parse.urlencode(dict)`	`urllib.parse.parse_qs(str)`
Java	`URLEncoder.encode(str, "UTF-8")`	`URLDecoder.decode(str, "UTF-8")`
Go	`url.QueryEscape(str)`	`url.QueryUnescape(str)`
PHP	`urlencode($str)`	`urldecode($str)`
Ruby	`ERB::Util.url_encode(str)`	`ERB::Util.url_decode(str)`
C#	`Uri.EscapeDataString(str)`	`Uri.UnescapeDataString(str)`
Rust	`urlencoding::encode(str)`	`urlencoding::decode(str)`

URL Encoding Cheat Sheet

Quick Decision Tree

You have a complete URL?       → use encodeURI()
You have a query param value?  → use encodeURIComponent()
You're debugging encoded data? → use decodeURIComponent()
Building query strings?        → use URLSearchParams() ✓

Characters That Must Always Be Encoded in Query Params

<space>  →  %20    # hash    →  %23
&        →  %26    % percent → %25
?        →  %3F    / slash  →  %2F
=        →  %3D    @ at     →  %40

TL;DR — Just Remember This

encodeURIComponent() for query parameter values (encodes everything)
encodeURI() only if you need to encode a complete URL string
Use URLSearchParams — it handles both encoding and parameter formatting
All encoding/decoding is local — no server processing required

🛠 Need a quick encode/decode? Try the URL Encoder / Decoder tool — built in the browser, safe with your sensitive data, supports both encoding modes. Also check out JSON Formatter and JWT Decoder for more handy dev tools.

Found this helpful? Follow me for more developer guides and practical web development tips. If you spot an error or have a suggestion, drop a comment below!

5 Developer Tools That Respect Your Privacy

kingfujing — Wed, 08 Jul 2026 08:13:57 +0000

Every day, developers paste sensitive data into online tools. API responses, JWT tokens, database dumps, configuration files — all uploaded to servers you don't control. Most free online tools process your data on their servers, which means they could log, analyze, or even sell it.

But it doesn't have to be this way. Modern browsers are incredibly powerful. Tools like JSON formatters, Base64 encoders, and even AI image processing can run entirely in your browser using JavaScript APIs — with zero server uploads.

This article covers five essential developer tools that respect your privacy by keeping your data local.

1. JSON Formatter & Validator

JSON is everywhere — API responses, config files, database exports. A JSON formatter is one of the most-used developer utilities, but many online JSON tools send your data to a server for parsing.

A privacy-first JSON formatter uses the browser's built-in JSON.parse() and JSON.stringify() — both available in every modern browser. Your API response with auth tokens, database config with connection strings, or any other sensitive data never needs to leave your machine.

Look for these signs of a privacy-respecting JSON tool:

"All data is processed locally" or "client-side only" statement
Works offline (disconnect your network and try it)
No account or sign-up required
Instant results with no loading spinners

2. Base64 Encoder / Decoder

Base64 encoding is used everywhere — from email attachments to JWT tokens to data URIs. A Base64 encoder/decoder might seem simple, but many implementations fail with Unicode characters like Chinese, Japanese, or emoji.

The privacy risk is real: if you're decoding JWT tokens (which often contain user IDs, email addresses, and other PII) in an online tool, that data is being transmitted to a remote server. A client-side Base64 tool uses the browser's native btoa() and atob() functions with Unicode workarounds, keeping everything local.

3. Regex Tester

Regular expressions are notoriously tricky to debug. A good regex tester with real-time highlighting can save hours of trial and error. But when you paste sensitive data (log files, user-generated content, email lists) into a server-side regex tester, you're giving away that data.

Client-side regex testers use JavaScript's RegExp engine — the same one that powers your browser. Support for named capture groups, lookahead assertions, Unicode property escapes — all available locally, with zero latency and zero privacy risk.

4. JWT Decoder

JSON Web Tokens are a cornerstone of modern authentication. When debugging auth issues, you often need to inspect a token's header and payload. But decoding a JWT in a web-based tool means sending your token (and potentially your users' data) across the network.

A client-side JWT decoder simply base64-decodes the three parts of the token right in your browser. No signature verification (which would require the server's secret — a huge security risk), just pure decoding. The tool can show you the expiration time, issuer, and all custom claims without any data leaving your machine.

5. AI ID Photo Maker

This one might surprise you. An AI-powered ID photo maker that runs entirely in your browser? Yes, it's possible. Using ONNX Runtime Web, the AI model for background removal runs locally via WebAssembly — your photo never leaves your device.

Compare this to typical "free" ID photo websites, which require you to upload your photo to their servers. Who knows what happens to that photo after you upload it? A local AI gives you the same result — professional background removal and standard sizes (1-inch, 2-inch) — with complete privacy.

How to Check If a Tool Respects Your Privacy

Here's a quick checklist:

Disconnect your internet — does the tool still work? If yes, it's fully client-side.
Check the browser's Network tab — are there any API calls when you use the tool?
Look for privacy statements — does the site explicitly say data stays local?
Check the source — many open-source tools are fully transparent about their processing.

Most online developer tools don't need to send your data anywhere. Between JavaScript's built-in APIs and modern WebAssembly, anything from JSON parsing to AI image processing can run locally. The next time you need a quick developer tool, choose one that keeps your data where it belongs — on your machine.

This article was originally published on DevToolsHub — free, privacy-first developer tools that run completely in your browser.

Unix Timestamp Cheat Sheet: Convert, Read, and Debug Like a Pro

kingfujing — Sun, 05 Jul 2026 14:50:24 +0000

Originally published on DevToolsHub — free, privacy-first online tools for developers.

Every developer hits timestamps at some point. JWT expiration (exp), API pagination cursors, database audit fields — Unix timestamps are everywhere. Yet they're one of the most common sources of confusion (and bugs).

This cheat sheet covers everything: conversion tricks, the seconds vs milliseconds trap, timezone gotchas, and one-liners for every major language.

⏱ Quick Try: Convert timestamps instantly with our free Timestamp Converter — supports seconds, milliseconds, and multiple timezone formats.

Quick Reference: Common Timestamps

Date/Time (UTC)	Unix (seconds)	Unix (ms)
Jan 1, 1970 00:00:00	0	0
Jan 1, 2000 00:00:00	946684800	946684800000
Jan 1, 2020 00:00:00	1577836800	1577836800000
Now (Jun 2026)	~1782000000	~1782000000000
Jan 19, 2038 03:14:07	2147483647 ⚠️	2147483647000 ⚠️

⚠️ Year 2038 Problem: The last row shows 2,147,483,647 — the maximum value for a signed 32-bit integer. After this point, 32-bit systems will overflow. Most modern systems use 64-bit timestamps (safe for 292 billion years), but embedded systems and legacy APIs may still be vulnerable.

The #1 Bug: Seconds vs Milliseconds

This is the most common timestamp bug in existence:

JavaScript Date.now() → milliseconds
Python time.time() → seconds (as float)
JWT exp claim → seconds
PostgreSQL EXTRACT(EPOCH FROM NOW()) → seconds
MySQL UNIX_TIMESTAMP() → seconds

Rule of thumb: If the value is around 1.7 billion → it's seconds. If it's around 1.7 trillion → it's milliseconds. The current epoch (June 2026) is about 1,782,000,000 in seconds.

Our Timestamp Converter automatically detects whether your input is seconds or milliseconds — just paste and it works.

One-Liners for Every Language

JavaScript / TypeScript

// Current time
Date.now()                         // -> 1782000000000 (ms)
Math.floor(Date.now() / 1000)      // -> 1782000000 (s)

// Timestamp to Date
new Date(1782000000000)            // -> 2026-06-24T... (ms)
new Date(1782000000 * 1000)        // -> same, but for seconds input

// Date to timestamp
new Date('2026-06-24').getTime()   // -> 1758585600000 (ms)
+new Date()                        // -> shorthand for Date.now()

// Format timestamp
new Date(1782000000000).toISOString()  // -> "2026-06-24T12:00:00.000Z"

Python

import time, datetime

# Current time
time.time()                        # -> 1782000000.123 (seconds, float)

# Timestamp to datetime
dt = datetime.datetime.fromtimestamp(1782000000)
print(dt.strftime('%Y-%m-%d %H:%M:%S'))

# Datetime to timestamp
dt = datetime.datetime(2026, 6, 24)
dt.timestamp()                     # -> 1758585600.0

# Timezone-aware (recommended)
from datetime import timezone
dt_utc = datetime.datetime.fromtimestamp(1782000000, tz=timezone.utc)

SQL (PostgreSQL)

-- Current Unix timestamp (seconds)
SELECT EXTRACT(EPOCH FROM NOW())::bigint;

-- Timestamp to date
SELECT to_timestamp(1782000000);

-- Date to timestamp
SELECT EXTRACT(EPOCH FROM TIMESTAMP '2026-06-24 12:00:00')::bigint;

-- Check if JWT is expired
SELECT 1782000000 > EXTRACT(EPOCH FROM NOW())::bigint; -- false = expired

Bash / Shell

# Current timestamp
date +%s                    # -> 1782000000 (seconds)

# Timestamp to date
date -d @1782000000         # macOS: date -r 1782000000

# Date to timestamp
date -d "2026-06-24" +%s   # -> 1758585600

# ISO format
date -u -d @1782000000 +"%Y-%m-%dT%H:%M:%SZ"

Java

// Current time (milliseconds)
System.currentTimeMillis();        // -> 1782000000000L

// Convert to seconds
System.currentTimeMillis() / 1000;

// Timestamp to Instant
Instant.ofEpochSecond(1782000000);
Instant.ofEpochMilli(1782000000000L);

// Format
Instant.now().toString();          // -> "2026-06-24T12:00:00Z"

// JWT exp check
long exp = 1782000000L;
boolean expired = Instant.now().getEpochSecond() > exp;

Go

// Current time
time.Now().Unix()              // -> 1782000000 (seconds)
time.Now().UnixMilli()         // -> 1782000000000 (ms)

// Timestamp to readable
t := time.Unix(1782000000, 0)
fmt.Println(t.Format(time.RFC3339))

// Parse to timestamp
t, _ := time.Parse(time.RFC3339, "2026-06-24T12:00:00Z")
t.Unix()                       // -> 1782000000

Rust

use std::time::{SystemTime, UNIX_EPOCH};

// Current timestamp
let now = SystemTime::now()
    .duration_since(UNIX_EPOCH)
    .unwrap();
println!("{}", now.as_secs());       // seconds
println!("{}", now.as_millis());      // ms

Common JWT Timestamp Patterns

If you're decoding JWTs (use our JWT Decoder), you'll frequently need to check these timestamp claims:

exp — Token expiration (always in seconds)
iat — Token issued at (seconds)
nbf — Not valid before (seconds)

Copy the exp value into the Timestamp Converter to instantly see if a token is expired — it color-codes expired vs valid.

Time Zones: The Hidden Trap

Unix timestamps are always UTC. They don't have a timezone. A timestamp of 1782000000 means the same moment everywhere on Earth — it's the display that varies by timezone.

When converting timestamps to readable dates:

Use ISO 8601 format (e.g., 2026-06-24T12:00:00Z) for communication between systems — the trailing Z means UTC
Only convert to local time when presenting to users
Never store timestamps in local time — always use Unix timestamps or UTC ISO strings

🎯 Summary: Unix timestamps = seconds since Jan 1, 1970 UTC. JS uses milliseconds, most backends use seconds. Timestamps are always UTC — timezone is a display concern. Use our Timestamp Converter for quick conversions and check JWT expiration with our JWT Decoder.

Related Tools: Timestamp Converter · JWT Decoder · UUID Generator

UUID v4 vs UUID v7: Which One Should You Use?

kingfujing — Sun, 05 Jul 2026 14:50:23 +0000

Originally published on DevToolsHub — free, privacy-first online tools for developers.

UUIDs (Universally Unique Identifiers) are everywhere in modern software development. But not all UUIDs are created equal. With the introduction of UUID v7 in RFC 9562 (May 2024), developers now have a compelling alternative to the ubiquitous UUID v4.

In this guide, we'll compare UUID v4 and UUID v7 across performance, database impact, sortability, and real-world use cases — so you can make the right choice for your next project.

💡 Quick Try: Use our free UUID Generator to generate UUID v4 and v7 right in your browser.

What is UUID v4?

UUID v4 is the most commonly used UUID version. It generates 122 bits of random data, making it effectively unique for practical purposes. The probability of collision is so low (about 1 in 5.3×10³⁶) that you can generate billions per second without worrying.

550e8400-e29b-41d4-a716-446655440000  (v4 example)
# The "4" in position 13 indicates UUID v4
# The version nibble (4) and variant (10xx) are fixed
# Everything else is random

Pros: Simple, battle-tested, available everywhere. Doesn't leak timing information.

Cons: Completely random — no natural ordering. This wreaks havoc on B-tree database indexes because new rows get inserted at random positions instead of appended.

What is UUID v7?

UUID v7 is the new kid on the block. It encodes a 48-bit Unix timestamp (millisecond precision) as its most significant bits, followed by random data. This makes v7 UUIDs time-sortable — you can sort them by creation time without storing a separate timestamp column.

018f0a56-1234-7b00-8a00-123456789abc  (v7 example)
# "018f0a56-1234" = Unix timestamp in milliseconds
# The "7" in position 13 indicates UUID v7
# Remaining bits are random for uniqueness

Pros: Time-ordered = database-friendly. Monotonically increasing = great for B-tree indexes. Encodes creation time without an extra column.

Cons: Newer standard — not all languages/libraries support it yet. Leaks approximate creation time (like auto-increment IDs).

Head-to-Head Comparison

Feature	UUID v4	UUID v7
Timestamp	None (random)	48-bit ms timestamp
Sortable	❌ No	✅ Yes (by time)
DB Index Friendly	❌ Bad (random inserts)	✅ Excellent (sequential)
Collision Resistance	122 random bits	74 random bits
Privacy	✅ No info leakage	⚠️ Leaks creation time
Library Support	✅ Universal	⚠️ Growing (2026+)
Standard	RFC 4122 (2005)	RFC 9562 (2024)

Database Performance: The Real Story

The biggest pain point with UUID v4 is database index fragmentation. PostgreSQL, MySQL, and most relational databases use B-tree indexes, which perform best when new rows have sequentially increasing primary keys.

With UUID v4, every insert lands at a random leaf position, causing:

Page splits — 50-100x more index maintenance
Cache misses — working set doesn't fit in memory
Write amplification — each insert touches multiple index pages

UUID v7 solves this elegantly. Since the timestamp is the leading bits, new UUIDs are monotonically increasing — new rows append to the rightmost index page. This gives you near-sequential performance without the coordination overhead of auto-increment.

When to Use Each

Use UUID v4 when:

You need unpredictable IDs (public API tokens, session IDs)
Privacy matters — v4 doesn't leak creation time
Your database is read-heavy with few writes (index fragmentation isn't an issue)
You're working in an environment without UUID v7 library support

Use UUID v7 when:

You're using UUIDs as primary keys in a write-heavy database
You want time-sortable identifiers without an extra column
You're designing a new system and can pick the latest libraries
Database index performance matters at scale (millions+ rows)

How to Generate UUID v7 in Different Languages

JavaScript / TypeScript

// UUID v7 is not yet in crypto.randomUUID() (still v4)
// Use a small helper:

function uuidv7() {
  const timestamp = Date.now();
  const hex = timestamp.toString(16).padStart(12, '0');
  const rest = Array.from({ length: 16 }, () =>
    Math.floor(Math.random() * 16).toString(16)
  ).join('');
  return `${hex.slice(0,8)}-${hex.slice(8,12)}-7${rest.slice(0,3)}-8${rest.slice(3,7)}-${rest.slice(7)}`;
}

console.log(uuidv7()); // "018f0a56-1234-7b00-8a00-123456789abc"

Python

import uuid
import time

def uuid7():
    timestamp = int(time.time() * 1000)
    hex_ts = f"{timestamp:012x}"
    rest = uuid.uuid4().hex[12:]
    return uuid.UUID(f"{hex_ts[:8]}-{hex_ts[8:12]}-7{rest[:3]}-8{rest[3:7]}-{rest[7:]}")

print(uuid7())  # UUID('018f0a56-1234-7b00-8a00-123456789abc')

PostgreSQL

-- If using pg_uuidv7 extension:
CREATE EXTENSION IF NOT EXISTS pg_uuidv7;
SELECT uuid_generate_v7();

-- Or just generate v4 (built-in, PostgreSQL 13+):
SELECT gen_random_uuid();

Final Verdict

🎯 Recommendation: For new projects that use UUIDs as database primary keys, start with UUID v7. The time-ordered structure gives you B-tree friendly insertion without sacrificing the global uniqueness that makes UUIDs valuable. Reserve UUID v4 for cases where unpredictability is a requirement — API keys, session tokens, or any identifier that must not reveal creation time.

Try generating both UUID versions instantly with our free online UUID Generator tool. It runs entirely in your browser — no server uploads, no data leaks.

Related Tools: UUID Generator · Timestamp Converter · Base64 Encoder/Decoder

How to Decode JWT Tokens Without a Backend

kingfujing — Thu, 02 Jul 2026 16:48:03 +0000

Originally published on DevToolsHub — free, privacy-first online tools for developers. All tools run in your browser; your data never touches any server.

If you've worked with authentication (OAuth, OpenID Connect, or any modern API), you've almost certainly encountered JWT (JSON Web Tokens). They're everywhere — but they can feel like a black box.

The good news: you don't need a backend to inspect a JWT. Since JWTs are base64url-encoded JSON, you can decode them entirely in your browser. In fact, that's the safest way to do it — your token data never leaves your machine.

🔐 Quick Try: Decode any JWT instantly with our free JWT Decoder tool — all client-side, no server uploads.

What is a JWT?

A JSON Web Token is a compact, URL-safe way to represent claims between two parties. A JWT looks like this:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

It has three parts, separated by dots: Header.Payload.Signature

Part 1: The Header

The header tells you how the token was created. Decode the first segment from base64url, and you'll get something like:

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

Key fields:

alg (Algorithm) — The signing algorithm. Common values: HS256 (HMAC+SHA256), RS256 (RSA+SHA256), EdDSA
typ (Type) — Usually "JWT"
kid (Key ID) — Optional. Identifies which key was used to sign

Part 2: The Payload (Claims)

This is the data part — the actual claims the token carries. Standardized claims include:

Claim	Name	Description
`iss`	Issuer	Who created the token
`sub`	Subject	Who/what the token is about (usually a user ID)
`aud`	Audience	Who should accept this token
`exp`	Expiration	Unix timestamp when token expires
`nbf`	Not Before	Token is not valid before this time
`iat`	Issued At	When the token was issued
`jti`	JWT ID	Unique identifier (prevents replay attacks)

Custom claims (like role, permissions, or email) are also common. Use our JWT Decoder to see exactly what your token contains.

Part 3: The Signature

The signature verifies that the token hasn't been tampered with. It's created by taking the header + payload, signing them with a secret key (for HMAC) or private key (for RSA/ECDSA), and base64url-encoding the result.

signature = HMACSHA256(
  base64urlEncode(header) + "." + base64urlEncode(payload),
  secretOrPrivateKey
)

⚠️ Important: Decoding a JWT does NOT verify the signature. You can read the payload without the secret key, but you need the server's secret to confirm the token is authentic. Never trust a decoded JWT without verification.

How to Decode a JWT Step by Step

You only need 3 steps. No server, no libraries:

Split by dots — Take your JWT and split on "." — you get three parts: [header, payload, signature]
Base64url decode the payload — Convert from base64url (use atob() in JS, but first replace - with + and _ with /)
Parse as JSON — JSON.parse() the decoded string — now you can read every claim

Or just use our JWT Decoder and paste your token — it does all three steps instantly, with syntax-highlighted output and expiration status.

Common JWT Security Pitfalls

1. The "none" Algorithm Attack

Older JWT libraries had a vulnerability where an attacker could change the algorithm to "none" and bypass signature verification. Always whitelist expected algorithms on the server side.

2. Storing JWTs in localStorage

While convenient, localStorage is accessible to any JavaScript running on the same origin. If your site has an XSS vulnerability, tokens can be stolen. Consider HttpOnly cookies for production applications.

3. Not Checking the exp Claim

Always verify the exp (expiration) claim on the server. An expired token should be rejected. Use our Timestamp Converter to check if a token's exp timestamp is still valid.

4. Decoding Without Verifying

This bears repeating: anyone can decode a JWT. The security comes from verifying the signature, which requires the server's secret key. Client-side tools like our JWT Decoder are great for debugging and inspection, but never trust the decoded data for authorization decisions.

Debugging JWTs Like a Pro

When debugging authentication issues, here's what to check with a JWT decoder:

Is the token expired? Check the exp claim against the current time
Is the issuer correct? Verify the iss claim matches your auth server
Is the audience correct? Check aud — your API should verify it
Are custom claims present? If your API expects a role or permissions claim, confirm it's there

Use our free JWT Decoder to inspect tokens quickly — it runs entirely in your browser, so your tokens stay private.

Related Tools:

10 Free Online Developer Tools You Need in 2026

kingfujing — Fri, 26 Jun 2026 01:27:46 +0000

Originally published on DevToolsHub — a collection of free, privacy-first online tools for developers.

Every developer has those moments — you need to quickly format some JSON, decode a Base64 string, or test a regex pattern, but you don't want to open a heavy IDE or risk pasting sensitive data into an unknown website.

I've been maintaining a collection of privacy-first developer tools that run entirely in your browser. Your data never touches any server. Here are 10 tools that I use almost daily.

1. 🔧 JSON Formatter & Validator

The most requested tool in any developer's arsenal. Paste messy JSON, hit format, and get beautifully indented output with syntax validation.

Why use it:

Format with adjustable indentation (2/4 spaces, tabs, minified)
Real-time error detection — highlights exactly where your JSON broke
Copy formatted output with one click

👉 Try it: DevToolsHub JSON Formatter

2. 🔄 Base64 Encoder / Decoder

Need to quickly encode an API token or decode a JWT header? Base64 encoding is everywhere in web development.

Why use it:

Full Unicode support (Chinese characters, emoji, etc.)
Automatic detection — paste Base64 and it auto-decodes
Toggle between encode/decode with one click

👉 Try it: DevToolsHub Base64

3. 🎯 Regex Tester with Live Preview

Regex is powerful but notoriously hard to debug. This tool gives you real-time matching feedback so you can see exactly what your pattern captures.

Why use it:

Live matching as you type (300ms debounce)
Supports all flags: g, i, m, s, u, y
Named capture groups (?<name>...) support
Highlighted matches in the test string

👉 Try it: DevToolsHub Regex Tester

4. 🔑 UUID Generator

Need a UUID for a database primary key, API identifier, or session token? Generate them in batches.

Why use it:

Generate 1, 5, 10, 25, 50, or 100 UUIDs at once
Uses crypto.randomUUID() — cryptographically secure
One-click copy all

👉 Try it: DevToolsHub UUID Generator

5. ⏱ Timestamp Converter

Unix timestamps are everywhere in APIs and databases. This bidirectional converter saves you from mental math.

Why use it:

Convert timestamp → human date, and date → timestamp
Auto-detects seconds vs milliseconds
"Now" button for current timestamp

👉 Try it: DevToolsHub Timestamp Converter

6. 🎨 Color Converter

Designers and frontend developers: need to convert between HEX, RGB, and HSL? This tool has you covered.

Why use it:

Auto-detects input format
Large color preview swatch
Copy any format with one click

👉 Try it: DevToolsHub Color Converter

7. 🔗 URL Encoder / Decoder

URL parameters with special characters breaking your API calls? Encode them properly.

Why use it:

Dual mode: encodeURI (preserves URL structure) or encodeURIComponent (encodes everything)
Swap button to quickly switch encode/decode
Clean output

👉 Try it: DevToolsHub URL Encoder/Decoder

8. 🔐 JWT Decoder

Inspect JWT tokens without a backend. Decode the header and payload to debug authentication flows.

Why use it:

Automatically splits header, payload, and signature
Shows expiry time with green/red status
Sample JWT pre-filled for testing

👉 Try it: DevToolsHub JWT Decoder

9. 📸 AI ID Photo Generator

Need a passport-style photo for your developer profile? This tool removes backgrounds and generates standard ID photos right in your browser.

Why use it:

Completely client-side — no uploads
Multiple standard photo sizes
Background removal with AI

👉 Try it: DevToolsHub AI ID Photo

10. 📋 UUID v4 vs v7 Comparison

Not a tool, but an essential read if you're deciding which UUID version to use in your next project.

👉 Read: UUID v4 vs v7: Which One to Use

Why These Tools Are Different

Most online developer tools upload your data to a server for processing. DevToolsHub does not.

✅ 100% client-side — all processing happens in your browser
✅ No data leaves your machine — perfect for sensitive data
✅ No account required — just open and use
✅ Free forever — no hidden limits or paywalls

What's Next?

I'm actively adding new tools. If there's something you'd like to see, let me know in the comments!

If you found this useful, consider bookmarking DevToolsHub or sharing it with a fellow developer.

The Complete Guide to Writing Better Regular Expressions

kingfujing — Sat, 20 Jun 2026 05:30:04 +0000

Originally published on DevToolsHub — a collection of free, privacy-first online developer tools.

Regular expressions are one of the most powerful — and most intimidating — tools in a developer's arsenal. They can validate an email in one line, extract data from messy logs, or replace patterns across thousands of files. But they can also produce unexpected results, suffer from catastrophic backtracking, or simply fail to match what you intended. This guide covers practical patterns, common traps, and expert techniques for writing better regex.

Start with a Regex Tester

Never write a complex regex without a tester. Live feedback is essential — it shows you exactly what matches, what does not, and why. The DevToolsHub Regex Tester provides real-time highlighting, flag toggles, and named group detection. Always test your pattern against multiple input strings before deploying it.

Understanding Regex Flags

Flags change how a regex pattern is interpreted. Here are the six most important flags in JavaScript:

Flag	Name	Effect
`g`	Global	Find all matches, not just the first one
`i`	Case-insensitive	Match both uppercase and lowercase
`m`	Multiline	`^` and `$` match start/end of each line
`s`	Dot All	Make `.` match newline characters too
`u`	Unicode	Enable Unicode property escapes like `\p{L}`
`y`	Sticky	Match only from `lastIndex` position

Practical Patterns for Everyday Use

Email Validation

A robust email regex is surprisingly complex. The official RFC 5322 regex is hundreds of characters long. For practical purposes, this pattern covers 99.9% of real email addresses:

/^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$/

URL Extraction

/https?:\/\/[\w\-._~:\/?#\[\]@!$&'()*+,;=]+/g

Password Strength (at least 8 chars, 1 upper, 1 lower, 1 digit)

/^(?=.*[a-z])(?=.*[A-Z])(?=.*\d).{8,}$/

This uses lookaheads ((?=...)) to check each condition without consuming characters.

Extract All Hex Colors from CSS

/#([a-fA-F0-9]{3}|[a-fA-F0-9]{6})\b/g

Named Capture Groups

JavaScript (ES2018+) supports named groups, which make your regex much more readable:

const logPattern = /(?<ip>\d+\.\d+\.\d+\.\d+) - - \[(?<date>[^\]]+)\]/;
const match = logPattern.exec('192.168.1.1 - - [19/Jun/2026:12:00:00]');
console.log(match.groups.ip);    // "192.168.1.1"
console.log(match.groups.date);  // "19/Jun/2026:12:00:00"

Named groups make complex patterns self-documenting and eliminate fragile index-based group references like match[1].

Common Regex Traps

1. Catastrophic Backtracking

Nested quantifiers like (a+)+b can cause exponential backtracking. On a long string of "a"s without a "b" at the end, the engine tries every possible split before giving up. This can freeze your application.

Fix: Use atomic groups (if supported) or rewrite to avoid nested quantifiers. Use possessive quantifiers like a++ where available.

2. Greedy vs Lazy Matching

By default, quantifiers are greedy — they match as much as possible. To match the minimum, add ? after the quantifier:

// Greedy: matches "<div>...</div><span>..." as one match
/<.*>/

// Lazy: matches each tag individually
/<.*?>/

3. Forgetting the Global Flag

Without the g flag, regex.exec() and String.match() return only the first match. Always add g when you need all occurrences.

Testing Your Regex

Even experienced developers write buggy regex on the first try. Always test your patterns against:

Valid input — does it match what you want?
Invalid input — does it correctly reject bad data?
Edge cases — empty strings, very long strings, strings with special characters
Performance — test with a large input to catch backtracking issues

Use the DevToolsHub Regex Tester to iterate quickly with live match highlighting. The 300ms debounce ensures instant feedback without performance lag.

Final Advice

Regex is a skill you build over time. Start with simple patterns, use named groups for readability, always test with a dedicated tool, and never nest quantifiers. With practice, you will go from fearing /^$REGEX$/ to wielding it with confidence.

If you found this guide useful, check out DevToolsHub for more free online developer tools. All tools run locally in your browser — your data never leaves your device.