DEV Community: Skojio Community

Verifying a JWT Signature: HS256 vs RS256 (and What exp Actually Means)

Skojio Community — Sat, 11 Jul 2026 10:05:03 +0000

If you've ever pasted a JWT into a debugger just to see three chunks of jumbled text and a green tick you didn't fully trust, this is for you. Decoding a JWT is the easy 90% of the job — reading the header and payload back as JSON takes one line of code. The part that actually matters for security — verifying the signature — is where most explanations either wave their hands or skip straight to "just use a library." This walks through what a JWT's three segments actually contain, how exp and the other standard claims work, and what it genuinely means to verify a signature for the two families you'll meet most often: HMAC (HS256) and public-key (RS256/ES256).

What a JWT actually is: three segments, not one blob

A JSON Web Token is three base64url-encoded pieces joined by dots:

header.payload.signature

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

// payload
{ "sub": "user_42", "iat": 1751500000, "exp": 1751503600 }

Base64url is not encryption — it's a reversible text encoding, the same way a QR code isn't a secret. Anyone holding a JWT can decode the header and payload themselves with nothing more than atob() and a JSON parser. This surprises people the first time they realise it: a JWT's contents are never confidential, only (potentially) tamper-evident. If you need to hide the payload's contents from the bearer of the token, a JWT is the wrong tool — that's what encrypted JWTs (JWE) or an opaque, server-side session token are for.

Never put anything you don't want the token holder to read in a JWT's payload — session IDs, role names, and user IDs are fine; raw passwords, unmasked card numbers, or anything you'd wince at appearing in a browser's devtools are not.

Reading the standard claims: what exp, iat, nbf, aud, iss actually mean

The payload can hold whatever your application needs, but RFC 7519 defines a handful of registered claims most real-world tokens use:

Claim	Meaning
`exp`	Expiry — Unix timestamp after which the token must be rejected
`iat`	Issued-at — Unix timestamp when the token was created
`nbf`	Not-before — Unix timestamp before which the token must NOT be accepted yet
`aud`	Audience — who the token is intended for
`iss`	Issuer — who created the token
`sub`	Subject — usually the user or account the token represents
`jti`	Unique token ID, often used to detect replay

The three time-based claims (exp, iat, nbf) are all plain Unix seconds — no timezone, no ISO string, just an integer. That's exactly why "is my token expired?" is a more annoying question to answer by eye than it should be: you have to convert the number to a date yourself, and get the units right (seconds, not milliseconds — a common off-by-1000 bug). A 1751503600 sitting in a payload tells you nothing at a glance; converted, it's a specific date and time you can actually reason about.

Decode first, verify second — and why the order matters

Given a token, there are two genuinely different questions you can ask:

"What does this token claim?" — answered by decoding. Split on the two dots, base64url-decode the header and payload, done. No key required, no trust implied.
"Should I believe what it claims?" — answered by verifying. This requires the correct key and tells you whether the header and payload have been altered since they were signed.

A worryingly common mistake is reading claims out of a decoded-but-unverified token and acting on them — trusting a role: admin claim, say, without ever checking the signature. If the payload is just base64-decoded JSON, it's exactly as trustworthy as a text file the user handed you: anyone can write {"role":"admin"} into it. Decoding without verifying tells you what a token says; only verification tells you whether it's true.

Verifying HS256: the shared-secret family

HS256 (and its longer siblings HS384, HS512) use HMAC — a single shared secret that both the issuer and the verifier must hold. Verification recomputes the HMAC over the token's first two segments (base64url(header) + "." + base64url(payload)) using that secret, and compares the result byte-for-byte against the signature segment.

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

If expected_signature matches the token's actual signature segment, the token is genuine and untampered — provided the secret itself was never leaked. That's HS256's whole trust model in one sentence: anyone who holds the secret can both sign new tokens and verify existing ones, which is fine for a single backend service checking its own tokens, and a liability the moment that secret needs to be shared across multiple services or handed to a third party.

Verifying RS256 and ES256: the public/private-key family

RS256 (RSA) and ES256 (ECDSA) split signing and verifying into two different keys. A private key signs; a completely separate, non-secret public key verifies. This solves HS256's sharing problem cleanly: an identity provider can publish its public key openly, and any number of services can verify tokens against it without ever holding anything sensitive.

signature = Sign(private_key, header + "." + payload)     // issuer only
is_valid  = Verify(public_key, header + "." + payload, signature)  // any verifier

RS256 uses RSA keys (typically PEM or JWK format); ES256 uses elliptic-curve keys, which are considerably smaller for equivalent strength — a practical reason ES256 has become popular where token size matters (URLs, headers, mobile). Either way, the shape of the trust model is identical: verifying a token never requires the private key, only the issuer's public key, which by design is safe to publish.

Two JWT security traps worth knowing by name

alg: none. The JWT spec allows a header to declare alg: none, meaning the token is deliberately unsigned — legitimate for some internal testing scenarios, but catastrophic if a verifier ever accepts one from the outside world without an explicit, deliberate opt-in. Some older or misconfigured libraries did exactly that: they read alg from the token itself and, on seeing none, skipped verification entirely — letting an attacker forge any payload they liked with zero key material. Any tool or library you use to inspect JWTs should flag alg: none loudly rather than quietly decode it as if nothing were wrong.

If you ever see alg: none on a token you didn't generate yourself for testing, treat it as a red flag, not a curiosity — it means the token carries no proof of integrity at all.

RS256-to-HS256 key confusion. This one is subtler. If a verifier trusts the alg value written in the token itself, an attacker can take a service's own — publicly available — RSA public key and resign a token with HS256, using that public key's bytes as the HMAC secret. A verifier that blindly does "whatever alg says, use this key" can end up HMAC-verifying against a key it never intended to be a shared secret, and pass. The fix lives entirely on the verifying side: pin the algorithm you expect (e.g. "this service only ever accepts RS256") rather than trusting the token to tell you what algorithm to use.

Try it: decode, verify, and build test tokens in one page

Skojio's JWT Decoder, Verifier & Encoder covers the whole loop described above in one page, entirely in your browser:

Paste a token to see its header and payload decoded and every standard claim humanised — including exp/iat/nbf converted to local date/time, not just a raw integer
An at-a-glance validity banner tells you expired / not-yet-valid / valid, with a relative time ("expired 3 days ago")
Verify HS256/384/512 against a shared secret, or RS256/384/512 and ES256/384/512 against a public key (PEM or JWK) — all via the browser's native WebCrypto, nothing sent anywhere
alg: none tokens get a non-dismissible warning instead of a silent pass, and pasting a public key against an HMAC-alg token triggers an explicit key-confusion warning
An Encode & Sign mode lets you build and sign a test token from scratch — handy for reproducing an expiry bug or a malformed-token scenario without reaching for a CLI

It doesn't claim to be more private than every other JWT tool out there — several others are also client-side. What it does offer is a complete, vendor-neutral page with no account, no marketing chrome, and both directions (decode/verify and encode/sign) covered for all nine mainstream algorithms in one place. If you need a shared secret for HS256 testing, Skojio's Password Generator will generate one; if you're inspecting the base64url encoding itself rather than a full token, Base64 Encoder/Decoder is the standalone version of that same step.

A JWT's header and payload are base64url-encoded, not encrypted — anyone holding the token can read them, so never put secrets in the payload
Decoding tells you what a token claims; only verifying its signature tells you whether to believe those claims
HS256 uses one shared secret for both signing and verifying; RS256/ES256 split signing (private key) from verifying (public key), which scales better across multiple services
exp, iat, and nbf are plain Unix-second timestamps — convert them to check expiry rather than eyeballing the raw integer
Watch for two specific traps: alg: none tokens that carry no signature at all, and RS256-to-HS256 key confusion, where a verifier that trusts the token's own alg field can be fooled into HMAC-checking against a public key

Funny Passphrases: Easy to Remember, Hard to Guess

Skojio Community — Thu, 09 Jul 2026 10:05:36 +0000

Most password advice boils down to "use more characters and more symbols" — sound advice, and also
the reason so many people end up with a password they can't actually remember and have to reset every
few weeks. A passphrase takes a different route to the same strength: instead of packing
randomness into a short string of mixed characters, it spreads that randomness across several whole
words. The result is longer to type but, done properly, considerably easier to recall.

Length beats complexity once you're past a basic threshold of character variety — a longer phrase of ordinary words can out-resist a short, symbol-heavy password.
A classic diceware generator draws each word independently from a huge, unrestricted wordlist — the "correct horse battery staple" approach.
A funny-sentence passphrase trades a little entropy per word for a vivid, memorable mini-story — useful, but only if the generator is honest about the trade-off.
Whichever style you use, generate it somewhere that runs entirely in your browser and never sends the result anywhere.

Why a random passphrase generator beats a character-soup password

A brute-force attacker has to search through every possible combination until they hit yours. What
matters for that search space is entropy — measured in bits, it's the number of times the number of
guesses doubles before your secret is found on average. Two things drive entropy up: how many
possible symbols could appear at each position, and how many positions there are.

Character-random passwords lean on the first lever: mixing uppercase, lowercase, digits, and symbols
widens the pool of possible characters at each slot. Passphrases lean on the second: instead of one
character per slot, each "slot" is an entire word drawn from a wordlist of thousands. Six words drawn
independently from a 7,776-word list carry roughly 77–78 bits of entropy — solidly in the "strong"
band — while being nothing more exotic to type than six ordinary words in a row.

"Correct horse battery staple": the diceware idea, explained

The phrase "correct horse battery staple" comes from a widely shared webcomic making exactly this
point: a short, symbol-heavy password can be weaker than a few unrelated words strung together,
despite looking scarier to type. The technique behind it — diceware — is simple and auditable:
roll dice (or, online, use a cryptographically secure random number generator) to pick words
independently from a fixed, public wordlist, then join them together. The EFF's long wordlist
(7,776 words, public domain) is the standard choice, and it's exactly what a proper diceware
generator should be drawing from — not a smaller, "curated for vibes" list that quietly reduces
your entropy without telling you.

The strength of a diceware passphrase is easy to check yourself: multiply your word count by
log2(wordlist size). Six words from the 7,776-word EFF list gives roughly 6 × 12.92 ≈
77.5 bits — no black box required.

The trade-off with plain diceware is memorability. Four or six unrelated nouns don't naturally link
together in your head, so you're still rote-memorising an arbitrary sequence — just a sequence of
words instead of characters.

When funny beats plain: the memorability trick

This is where a funny password generator approach earns its place, provided it's honest about
what it's doing. Instead of drawing unrelated words, a grammar-template generator arranges words into
a fixed slot order — adjective, noun, verb, and so on — so the output reads as a tiny, absurd
sentence rather than a word list. "angry-teapot-juggles-purple-donkeys" forms a mental picture in a
way that four random nouns never quite manage, which genuinely helps recall.

The honest catch: each slot in a grammar template is drawn from a smaller, purpose-built list (the
adjective list, the noun list, the verb list) rather than one enormous shared wordlist, so the
entropy per word is usually lower than free-form diceware. A tool that quietly skips over this either
doesn't understand its own maths or doesn't want you to notice. Skojio's Passphrase Generator shows
the exact bit count for whichever mode you're in, plus a standing note whenever the funny-sentence
mode is active, reminding you to switch to Classic Diceware, use the longer template, or add extra
digits and symbols if you need maximum resistance.

Numbers, symbols, and separators — do they matter?

Adding one or two random digits, or a single symbol, contributes a small, disclosed amount of extra
entropy on top of your word-based bits. It's a genuine bonus, but it isn't a substitute for enough
words — three digits add roughly 10 bits, while a single extra six-letter word typically adds far
more. Separators (hyphens, periods, spaces) don't affect entropy at all; pick whichever is easiest to
type on the keyboard or device you'll be using the passphrase with, and avoid a letter-or-digit
separator that could visually blend into the words either side of it. If a site specifically demands
digits and symbols, a passphrase generator with numbers and symbols support (rather than one that
only ever outputs bare words) lets you satisfy that policy without giving up the memorability.

Password vs passphrase: which should you use?

Neither replaces the other — they suit different situations:

Passphrase: master password for a password manager, Wi-Fi network password, device unlock code, or a recovery phrase you need to recall without writing it down. Anywhere you'll actually type or remember the secret yourself, length-based passphrases are usually the easier win.
Password: an individual site login you'll only ever paste from a password manager. Here, a short, maximum-entropy, fully random string generated by Skojio's Password Generator is the more familiar, equally strong fit — you never have to type or remember it at all.

Try it yourself

Skojio's Passphrase Generator runs both approaches side by side: a
Funny Sentence mode for something memorable, and a Classic Diceware mode using the full EFF long
wordlist, with one transparent, mode-aware entropy meter for whichever you pick. Everything is
generated using the browser's own cryptographically secure random number generator — nothing you
generate is ever sent to a server, stored, or logged.

Length beats complexity — a passphrase of ordinary words can out-resist a short, symbol-heavy
password, and it's far easier to actually remember.

If you'd rather keep the character-random style for logins you'll always paste from a manager,
Skojio's Password Generator covers that case with the same bulk
generation, export, and honest strength metre.

How to Convert SOAP XML to JSON (and Back) Without Losing Attributes or Namespaces

Skojio Community — Thu, 09 Jul 2026 10:05:05 +0000

Anyone who has had to debug a SOAP integration knows the moment: you're staring at a namespaced, attribute-heavy XML envelope, you need to inspect or mock it as JSON for a script or test fixture, and the free converter you paste it into either drops the attributes, strips the namespace prefixes, or turns a single <Role> element into a plain string one day and an array the next. None of that is a coincidence — it's what happens when a converter uses a fixed, undocumented convention instead of a stated one. This guide walks through what that convention actually needs to cover, using a SOAP envelope as the running example, since legacy SOAP and WSDL interop is one of the most common reasons anyone reaches for an XML-to-JSON tool in the first place.

Why SOAP and WSDL interop keeps needing this conversion

SOAP services, and the WSDL documents that describe them, are still very much alive in enterprise and government systems, banking middleware, and older internal APIs that nobody has had the time (or the budget) to migrate to REST. When a developer needs to inspect a SOAP response, write a test fixture against it, or mock its shape in a modern JavaScript or Python project, JSON is the natural working format — but hand-converting a real SOAP envelope quickly runs into exactly the details that trip up ad-hoc scripts: attributes, mixed text-and-element content, namespace prefixes, and elements that are sometimes singular and sometimes repeated.

A WSDL file is worth calling out specifically, because the honest answer for wsdl xml to json is more modest than it sounds: a WSDL document is just XML, so a general-purpose XML-to-JSON converter handles its structure fine — but it has no special understanding of what a <wsdl:operation> or <wsdl:binding> means semantically. That's a job for WSDL-aware tooling, not a format converter. Treating WSDL as generic, structurally-converted XML is the correct scope for this kind of tool, not a limitation to apologise for.

XML attributes to JSON: the `@`-prefix convention

Take a simple attributed element:

<GetUserResponse id="42">
  <Name>Ada Lovelace</Name>
</GetUserResponse>

The most common lossless convention prefixes attribute names so they can never collide with a child element sharing the same name:

{
  "GetUserResponse": {
    "@id": "42",
    "Name": "Ada Lovelace"
  }
}

Some converters instead offer a "merge attributes as plain keys" option, dropping the @ for a cleaner-looking {"id": "42", "Name": "..."}. That's a legitimate choice for simple documents, but it's genuinely lossy: if this element also had a child element literally named <id>, the attribute and the child would overwrite each other in the merged JSON with no warning. A converter should let you choose, but should also tell you, on the page, exactly when that choice is risky.

Element text, and when it needs a `#text` key

A plain leaf element with only text content should collapse to a simple JSON value — there's no reason <Name>Ada Lovelace</Name> needs to become {"Name": {"#text": "Ada Lovelace"}} when it has no attributes or children to also represent. The #text key (or whatever marker you configure) only earns its place once an element has both text content and attributes or children to sit alongside it:

<Price currency="GBP">42.50</Price>

{
  "Price": { "@currency": "GBP", "#text": "42.50" }
}

Getting this collapse rule right is what keeps the common case — a document full of simple leaf elements — from turning into noisy, wrapper-object JSON that's unpleasant to work with downstream.

Namespaces: keep the prefix, or strip it deliberately

This is where xml to json with namespaces queries usually run into trouble. A SOAP envelope is namespaced from the very first tag:

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
  <soap:Body>
    <GetUserResponse id="42">
      <Name>Ada Lovelace</Name>
    </GetUserResponse>
  </soap:Body>
</soap:Envelope>

The lossless default is to keep the prefix exactly as written in the JSON key — soap:Envelope, soap:Body — rather than resolving it to the namespace URI it's declared against, or silently stripping it to a bare Envelope. The xmlns:soap declaration itself just becomes an ordinary @xmlns:soap attribute on the element that declared it; it isn't specially resolved or merged across scopes. Stripping prefixes for a cleaner-looking key is a reasonable option — plenty of people genuinely don't need the prefix for their downstream use — but it should be a visible toggle, not the only behaviour on offer, because two differently-prefixed elements sharing a local name would otherwise collapse into the same JSON key and silently overwrite each other.

If you're converting a SOAP envelope specifically to inspect the body payload and don't care about the envelope/header wrapper, it's usually faster to convert the whole document once with namespaces preserved, then just navigate into soap:Body in the resulting JSON — rather than trying to strip the envelope out beforehand and risking a malformed fragment.

XML arrays to JSON: repeated elements, not a fixed schema

XML has no native array type — repetition is the only signal. When the same tag name appears more than once under the same parent, in document order, that's an array:

<User>
  <Name>Ada Lovelace</Name>
  <Role>Admin</Role>
  <Role>Analyst</Role>
</User>

{
  "User": {
    "Name": "Ada Lovelace",
    "Role": ["Admin", "Analyst"]
  }
}

The detail that trips up naive converters: a single occurrence of <Role> should stay a plain string, not get force-wrapped into a one-item array just because the schema theoretically allows repetition. If it did, every consumer of the JSON would have to write Array.isArray(user.Role) ? user.Role : [user.Role] defensively on every field that might repeat — which defeats the point of a clean conversion. Comments and processing instructions, meanwhile, are simply dropped; they were never part of the data, only the markup.

Going the other way: JSON to XML online, correctly

The reverse direction needs the literal inverse of every rule above, applied consistently:

{
  "GetUserResponse": {
    "@id": "42",
    "Name": "Ada Lovelace",
    "Role": ["Admin", "Analyst"]
  }
}

<GetUserResponse id="42">
  <Name>Ada Lovelace</Name>
  <Role>Admin</Role>
  <Role>Analyst</Role>
</GetUserResponse>

Keys matching your attribute prefix become attributes again, arrays repeat as sibling elements sharing the array's key as the tag name, and reserved XML characters (<, >, &, ", ') need correct escaping in both element text and attribute values. If the root JSON value is a single-key object, that key can become the XML root tag directly; an array or a multi-key object needs an explicit root element name, since XML — unlike JSON — always needs exactly one top-level element.

If you want to sanity-check that a JSON payload is well-formed before converting it to XML — particularly useful when you've hand-edited a fixture — a plain JSON formatter and validator is worth running first.

Round-trip fidelity: why the settings have to be shared, not duplicated

The real test of an XML ↔ JSON tool is whether XML → JSON → XML actually reproduces your original document. That only holds if the attribute prefix, text-content key, namespace handling, and array rule are the literal inverse of each other in both directions — which in practice means both directions need to read from one shared settings object, not two independently-built converters bolted together on the same page. A tool where "convert to JSON" and "convert to XML" were implemented separately, even by the same author, will drift the moment one side's default changes and the other doesn't.

Try it: an XML ↔ JSON converter built around round-trip fidelity

We built Skojio's XML ↔ JSON Converter specifically to make this convention visible, shared, and symmetric rather than fixed and hidden. It supports:

A configurable attribute prefix (@ or $, or merge-as-plain-keys with an on-page warning about when that's lossy)
A configurable text-content key, applied only when an element also has attributes or children
Namespace prefixes kept by default (the lossless choice), with an optional strip-prefix toggle
Repeated-sibling-to-array conversion that never force-wraps a single occurrence
A built-in "Load SOAP example" button that seeds a representative, namespaced envelope so you can see the whole conversion in one click
A one-click "Verify round-trip" action that sends your output straight back through the other direction

Everything runs in your browser via the native DOMParser and hand-rolled JavaScript — nothing you paste or upload is sent to a server, and there's no external entity or DTD fetching, so there's no XXE risk either. It's a natural complement to JSON Formatter & Validator for checking structure first, and to JSON ↔ CSV Converter if the same data eventually needs to land in a spreadsheet instead of a legacy XML endpoint.

SOAP and WSDL interop is one of the most common reasons developers need an XML ↔ JSON converter — treat WSDL as generic XML, not something requiring semantic understanding of its operations.
XML attributes need a visible, consistent convention (commonly an @ prefix) to avoid silently colliding with child elements of the same name.
Namespace prefixes should be kept by default (soap:Envelope), not silently stripped or resolved — stripping is a lossy option, not the only behaviour.
Repeated sibling elements become a JSON array in document order; a single occurrence must stay a plain value, never force-wrapped.
Round-trip fidelity (XML → JSON → XML) only holds if both directions share one settings object rather than independently guessing at the same conventions.

AGENTS.md, Explained: One File for Claude, Cursor, Copilot and Windsurf

Skojio Community — Thu, 09 Jul 2026 10:05:04 +0000

If you use more than one AI coding agent on the same project, you've probably noticed the file sprawl: an AGENTS.md, a CLAUDE.md, a .cursor/rules/ directory, a .github/copilot-instructions.md, maybe a .windsurf/rules/. They all say roughly the same thing — how to build the project, what conventions to follow — and they all drift apart the moment you change one and forget the others.

This post explains what AGENTS.md is, why it exists, and how to keep the whole set in sync without hand-copying between formats.

What AGENTS.md actually is

AGENTS.md is a plain-Markdown file at your repository root that tells an AI coding agent what it needs to know about your project. There are no required fields and no special schema — just Markdown headings you'd recognise from any README:

# Project overview
A Next.js + TypeScript application.

## Setup / install
npm install

## Build, test, and lint
Build: npm run build
Test: npm test
Lint: npm run lint

## Code style and conventions
- TypeScript strict mode — avoid `any` without good reason.
- Prefer server components; add "use client" only where needed.

What makes it more than a convention is adoption. In December 2025, AGENTS.md was donated to the Linux Foundation's Agentic AI Foundation as an open standard, and it's now read natively by Claude Code, Codex, Cursor, Copilot, Gemini CLI, Windsurf, Zed, Aider and roughly thirty other agents. For most tools, a single good AGENTS.md is all you need.

Because AGENTS.md has no required fields, the fastest way to write a good one is to start from a stack-appropriate skeleton — overview, setup, build/test/lint, conventions — and fill in your real commands. That's what the stack presets in the tool below do.

Why you still end up with five files

If everything read AGENTS.md, this would be a non-problem. Two things keep the sprawl alive:

A few agents have their own established file. Claude Code looks for CLAUDE.md; Cursor has its .cursor/rules/ directory; older setups still carry a .cursorrules or .windsurfrules.
Cursor does something the others don't: per-file scoping. A Cursor rule can be limited to specific globs, which is genuinely useful and has no equivalent in a flat file.

So teams copy the same content into each file, and then the copies rot. A build command changes in AGENTS.md and nobody updates CLAUDE.md. A new convention lands in the Cursor rules and never makes it to Copilot. The files that were meant to keep your agents consistent quietly make them inconsistent.

The fix for CLAUDE.md: bridge, don't duplicate

The most common mistake is pasting your whole AGENTS.md into CLAUDE.md. Don't. Claude Code supports importing another file with an @-reference on the first line, so the recommended CLAUDE.md is a one-line bridge plus only what's genuinely Claude-specific:

@AGENTS.md

## Claude-specific overrides
- Prefer running the test suite with the focused `-t` flag during iteration.

Now the shared instructions live in exactly one place. CLAUDE.md inherits them through the @AGENTS.md import and adds nothing it doesn't need to.

Converting Cursor rules to AGENTS.md (and the glob caveat)

This is the conversion people search for most — "cursor rules to agents.md" — and it's the one with a real subtlety. A Cursor rule is an .mdc file with YAML frontmatter:

---
description: "Testing conventions"
globs: **/*.test.ts, **/*.spec.ts
alwaysApply: false
---
Use Vitest. Co-locate tests with the code they cover.

Converting the body to AGENTS.md is trivial — it's already Markdown. The catch is the globs line. That rule only applies to test files, but AGENTS.md is flat: it applies to the whole project and has no way to express "only for **/*.test.ts".

When a converter flattens a scoped Cursor rule, the scoping is lost. The honest thing to do is record the original glob verbatim — not drop it silently. A rule you think is still scoped, but isn't, is worse than one you know is global.

A good conversion therefore keeps the information visible. Instead of throwing the glob away, it appends the scoped rule under a labelled section and notes where it came from:

## Scoped rules (originally Cursor-only)

### testing-conventions — Testing conventions
> Originally scoped to: **/*.test.ts, **/*.spec.ts

Use Vitest. Co-locate tests with the code they cover.

You keep the content, you can see exactly what was scoped, and you decide what to do about it — rather than a converter quietly pretending the scope survived.

.cursorrules and .windsurfrules are deprecated — read them, don't write them

If you're still carrying a single-file .cursorrules or .windsurfrules, those formats are deprecated. Cursor moved to a .cursor/rules/ directory of .mdc files; Windsurf moved to .windsurf/rules/. The right migration is one-way: read the old single file to recover its content, then emit the current directory-based format. There's no reason to generate a new .cursorrules in 2026.

Doing it without hand-copying

All of the above is mechanical, which means you shouldn't be doing it by hand. Skojio's AGENTS.md Generator & Converter treats AGENTS.md as the single source of truth and derives the rest from it:

Stack presets — Next.js + TypeScript, Python, Go, Rust, Node.js, or Generic — seed a sensible starting AGENTS.md so you're editing, not staring at a blank file.
Live format tabs show the CLAUDE.md bridge, Cursor .mdc rules (with real frontmatter and multi-block scoping), Copilot and Windsurf equivalents as you type.
Import an existing file in any of the formats — including deprecated .cursorrules and .windsurfrules — and convert to the others.
The glob caveat is surfaced, not hidden: convert a scoped Cursor rule to a flat format and you get the verbatim record shown above plus a plain-language warning.
Copy any file, or download all five at once as a .zip laid out at the correct paths for a drop-in.

It runs entirely in your browser — nothing you paste or upload is sent anywhere, which matters when the file you're editing describes your private repository. If you work with JSON alongside your agent config, the same in-browser, privacy-first approach powers Skojio's JSON Formatter & Validator and JSON to TypeScript Converter.

AGENTS.md is an open standard (Linux Foundation, Dec 2025) read natively by ~30 AI coding agents — for most tools, one good AGENTS.md is enough.
The sprawl persists because a few agents keep their own file (CLAUDE.md, Cursor rules) and Cursor adds per-file glob scoping the flat formats can't express.
Write CLAUDE.md as a one-line @AGENTS.md bridge plus overrides — never a duplicate that drifts.
Converting scoped Cursor rules to a flat format loses the scoping; a good converter records the original glob verbatim instead of dropping it silently.
.cursorrules and .windsurfrules are deprecated — read them to migrate, but emit the current .cursor/rules/ and .windsurf/rules/ directory formats.

99.9% Uptime: How Much Downtime Is That, Really? (Plus Combined SLA)

Skojio Community — Wed, 08 Jul 2026 10:05:35 +0000

"99.9% uptime" sounds like a small, almost meaningless gap from perfect. In practice it's the difference between an outage nobody notices and one that ends up in a postmortem. Whether you're reading a vendor's SLA, writing an incident report, or trying to work out what your app's real availability is once you account for the database, the CDN, and the auth provider it depends on, the maths behind "the nines" is simple once you see it laid out — and easy to get subtly wrong (most people average SLAs together when they should be multiplying them). This is a walkthrough of both.

99.9% uptime ("three nines") allows about 8 hours 45 minutes 36 seconds of downtime a year on the standard 365-day convention
Each extra nine cuts permitted downtime by roughly a factor of ten
For services that depend on each other, multiply availabilities together — never average them
Two services each at 99.9% combine to about 99.8%, not 99.9% — a real, common mistake
The year/month length convention you use (365 vs 365.25 days, fixed vs calendar-average month) changes every downtime figure, so check it before comparing two SLA calculators

What Does 99.9% Uptime Actually Mean?

"99.9% uptime" is a percentage of time, not a vague quality score. To turn it into something concrete, take the length of the reporting period and multiply it by the 0.1% that's allowed to be down. On the 365-day year / calendar-average month convention (30.44 days — the convention this calculator defaults to, since it's the one most billing and monitoring periods actually use):

Period	Downtime allowed at 99.9%
Daily	1 minute 26 seconds
Weekly	10 minutes 5 seconds
Monthly	43 minutes 50 seconds
Quarterly	2 hours 11 minutes 24 seconds
Yearly	8 hours 45 minutes 36 seconds

These numbers move if the convention moves. A 365.25-day year (accounting for leap years) or a fixed 30-day month instead of the 30.44-day calendar average both produce slightly different figures — which is exactly why two SLA calculators can disagree on "the same" percentage without either being wrong. Check which convention a vendor's number assumes before you compare it to your own monitoring dashboard.

The Nines, From One to Six

Each additional "nine" in an uptime percentage cuts the permitted downtime by roughly a factor of ten. Here's the full reference table, again on the 365-day convention:

SLA	Common name	Downtime per year
90%	one nine	about 36 days 12 hours
95%	one and a half nines	about 18 days 6 hours
99%	two nines	about 3 days 15 hours 36 minutes
99.5%	two and a half nines	about 1 day 19 hours 48 minutes
99.9%	three nines	8 hours 45 minutes 36 seconds
99.95%	three and a half nines	4 hours 22 minutes 48 seconds
99.99%	four nines	52 minutes 34 seconds
99.995%	four and a half nines	26 minutes 17 seconds
99.999%	five nines	5 minutes 15 seconds
99.9999%	six nines	about 32 seconds

Five nines gets quoted constantly as the gold standard for critical infrastructure — telecoms switches, payment rails — but it's worth noticing how little slack it leaves: barely five minutes a year across every dependency, not just the headline service.

How to Convert an Outage Into an Uptime Percentage

The forward direction (percentage → downtime) is the easy half. The other direction comes up just as often: you had an outage, and you need to report what percentage uptime that represents — for a postmortem, an SLA breach claim, or just your own dashboard.

The maths is the mirror image of the table above: divide the downtime by the length of the period, subtract that fraction from 1, and multiply by 100. A 42-minute outage in a 30-day month, for instance, works out to roughly 99.903% uptime for that month — comfortably inside a 99.9% SLA, but worth checking against the exact contractual period length rather than eyeballing it.

For odd, non-calendar windows — "we were down from 14:32 to 15:14 on the 12th" — a fixed day/week/month bucket doesn't apply cleanly. A custom date-range mode that takes an exact start and end timestamp plus the outage duration avoids rounding a postmortem window into the nearest calendar period.

Combined SLA for Dependent Services: Why You Can't Just Average

This is the part most SLA discussions skip, and it's where the real mistakes happen. If your application depends on a database, a CDN, and an auth provider — and any one of them failing takes the whole app down — the application's actual achievable uptime isn't the average of the three SLAs. It's their product.

Two services each individually rated at 99.9% don't combine to 99.9%. They combine to:

0.999 × 0.999 = 0.998001 → 99.8001% ≈ 99.8%

That's roughly 17.5 hours of downtime a year — about double what either service alone would suggest — simply because both need to be up at the same time, and each has its own independent chance of failing.

Add a third hard dependency and it compounds further. Three services individually rated at 99.9%, 99.99%, and 99.95% combine to:

0.999 × 0.9999 × 0.9995 ≈ 0.998401 → 99.84%

— about 14 hours of downtime a year, worse than any single link in the chain, even though two of those three services individually look excellent on paper.

This only applies to serial, hard dependencies — where the whole system genuinely fails if any one component fails. It does not apply to redundant or failover (parallel) architectures, where a single component going down doesn't take the system with it. Multiplying availabilities for a redundant setup would understate its real resilience, not overstate it — different maths for a different architecture.

Comparing Vendor SLAs Side by Side

The last piece worth flagging: when you're comparing cloud providers or hosting plans — "AWS's 99.99% vs this vendor's 99.95%" — don't stop at the headline percentage. Line up the actual downtime figures for the periods that matter to you (monthly is usually the one that maps to billing credits), and check both vendors are quoting the same year/month convention. A 0.04 percentage-point gap sounds trivial until you see it's the difference between about 4 minutes and about 22 minutes of permitted downtime a month.

Try It Yourself

Doing any of this arithmetic by hand is fiddly and easy to get subtly wrong — particularly the averaging-vs-multiplying trap above, which even experienced engineers reach for under time pressure. Skojio's SLA uptime calculator covers all five directions in one tool: forward (percentage → downtime), reverse (outage → percentage), a custom date-range mode for postmortems, a compound/chained calculator that multiplies dependent services correctly, and a side-by-side comparison table for vendor SLAs — with the year/month convention exposed as an explicit, switchable toggle rather than silently hardcoded. It runs entirely in your browser: nothing you type ever leaves your device.

If SLA maths brought you here, a few of Skojio's other free browser-based infra tools are worth a look too: the Chmod Calculator for the other everyday Linux/Unix arithmetic, the Cron Expression Helper for scheduling maintenance windows around whatever downtime budget you've got left, and the Timezone Helper for making sure "this month" means the same thing to everyone on a distributed team.

How to Generate TypeScript Types from JSON (Without Getting Optional Fields Wrong)

Skojio Community — Wed, 08 Jul 2026 10:05:03 +0000

If you've ever pasted a single JSON object into a "json to typescript" tool and gotten back a clean interface, only to have your API return a slightly different shape the next day and blow up your build — you've hit the single-sample problem. It's the most common, least talked-about failure mode in JSON-to-TypeScript conversion, and it's worth understanding before you trust any generated type in a real codebase.

What "generate TypeScript types from JSON" actually means

At its core, converting JSON to TypeScript is a structural mapping exercise. JSON has a small set of value types — string, number, boolean, null, array, object — and each one has an obvious TypeScript counterpart:

{
  "id": 42,
  "name": "Ada Lovelace",
  "active": true
}

export interface Root {
  id: number;
  name: string;
  active: boolean;
}

For a single, simple object, that's the whole job. The complexity — and the part where converters genuinely differ in quality — shows up the moment your JSON sample is an array of objects, which is the shape almost every real REST API response actually has.

The single-sample problem: why optional fields go missing

Here's the trap. Say your API returns a list of users, and one of them is missing an email field because they signed up via SSO:

[
  { "id": 1, "name": "Ada", "email": "ada@example.com" },
  { "id": 2, "name": "Alan" }
]

A converter that only looks at the first array element will produce:

export interface Root {
  id: number;
  name: string;
  email: string;
}

That's wrong — email is not guaranteed to be present, but the generated type says it is. The bug won't show up immediately. It shows up later, as a runtime undefined where TypeScript swore a string would be, because nothing forced the compiler to check the field that was actually missing in your sample data.

This is the single biggest correctness gap across the free "json to typescript interface generator" tools you'll find in a search: most infer structure from element 0 of an array (or the one object you pasted) and never look at the rest.

What correct multi-sample merging looks like

The fix is straightforward in concept, if fiddly to implement correctly: when the JSON root is an array of similar objects, merge the union of every key seen across every element — not just the first — into one interface.

export interface Root {
  id: number;
  name: string;
  email?: string; // absent from at least one sample
}

The same logic applies to types, not just presence. If a field is a number in one record and a string in another — a common pattern when an API is mid-migration, or a field is sometimes an ID and sometimes a slug — proper merging produces a union:

[{ "value": 42 }, { "value": "forty-two" }]

export interface Root {
  value: number | string;
}

A converter that samples only the first element would type value as number and quietly break the moment it saw a string. This matters just as much for nested arrays of objects: if a tags array inside one record has an item missing a weight field, that optionality has to survive being merged again when the outer records themselves get merged together — a subtlety that's easy to get right for a single level of nesting and easy to lose once you go two levels deep.

Handling JSON to TypeScript nested objects

Nested objects raise a second, separate design question: should the nested shape be written inline, or pulled out into its own named interface?

{
  "id": 1,
  "address": { "city": "London", "postcode": "SW1A 1AA" }
}

Inline keeps everything in one block:

export interface Root {
  id: number;
  address: { city: string; postcode: string };
}

Extracted gives the nested shape its own name, which is usually more readable and lets you reuse the type elsewhere:

export interface Address {
  city: string;
  postcode: string;
}

export interface Root {
  id: number;
  address: Address;
}

Extraction is generally the better default for anything beyond a trivial one-off shape, especially if the same nested structure appears under more than one property (a billingAddress and shippingAddress with identical fields, for instance) — a good tool should deduplicate those into a single interface rather than generating two identical ones with different names.

Other details worth checking before you trust a converter's output

A handful of smaller rules separate a converter that produces compiling, correct TypeScript from one that produces something that merely looks right:

Empty arrays should infer as unknown[], not silently any[] — an empty array genuinely tells you nothing about its element type, and any defeats the entire point of generating types in the first place.
Keys that aren't valid TypeScript identifiers — hyphens, spaces, a leading digit, reserved words — need automatic quoting ("last-login": string;), or the output won't compile at all.
null values should be handled explicitly, either as an honest T | null union or folded into key?: T depending on your team's convention — never silently dropped.
export and readonly should be simple toggles you control, not a hard-coded style choice you have to find-and-replace after the fact.

Try it: a json to typescript converter built around correct merging

Skojio's JSON to TypeScript Converter exists specifically to close the single-sample gap described above. Paste a JSON object or an array of objects and it will:

Merge the union of keys across every array element (not just the first) to correctly infer optional fields and unions
Recursively apply the same merging to nested arrays of objects, so optionality survives being merged at multiple levels
Let you toggle interface vs type, extract-named-interfaces vs inline nesting, export, and readonly
Automatically quote invalid-identifier keys, with a visible note when it happens
Give you a copy button and a one-click .ts download

Everything runs in your browser — nothing you paste is sent anywhere. If you want to check your JSON's shape is well-formed before generating types from it, run it through JSON Formatter & Validator first; if you'd rather get the same data into tabular CSV instead of TypeScript, JSON ↔ CSV Converter is the same-input, different-output sibling tool.

Most free JSON-to-TypeScript converters infer structure from a single sample (often just array element 0), which silently mis-types fields that are sometimes missing or sometimes a different type.
Correct multi-sample merging unions the keys across every array element: absent-in-some-records becomes key?: T, differently-typed-across-records becomes a union type.
Nested arrays of objects need the same merge logic applied recursively — optionality discovered one level down has to survive being merged again at the level above.
Extracting nested objects into named, deduplicated interfaces is usually more useful than writing them inline, especially when the same shape appears under more than one property.
Empty arrays should infer as unknown[], not any[]; invalid-identifier keys need automatic quoting, not a compile error.

How to Flatten Nested JSON to CSV (and Convert It Back Without Losing Data)

Skojio Community — Wed, 08 Jul 2026 10:05:02 +0000

Ask anyone who has piped an API response into a spreadsheet for a stakeholder how it went, and you'll usually hear the same complaint: it worked fine until the JSON had a nested object, an array, or a comma inside a text field, and then the CSV came out wrong — misaligned columns, mangled quotes, or every value turned into text. This guide covers what actually needs to happen underneath a JSON-to-CSV conversion (and the reverse), so you can either build it correctly yourself or know exactly what to look for in a tool that claims to handle it.

Why nested JSON breaks naive CSV export

CSV is fundamentally a flat, two-dimensional format — rows and columns, nothing more. JSON has no such restriction: values can be objects, arrays, or arrays of objects, nested arbitrarily deep. The moment you try to represent {"user": {"name": "Ada", "address": {"city": "London"}}} as a spreadsheet row, you have to make a decision JSON never forced you to make: how does a deeply nested value become a single flat cell, or a set of flat cells?

Most quick scripts skip this decision entirely and either crash on nested data, silently drop it, or JSON.stringify() the whole nested value into one unreadable cell without telling you that's what happened. None of those are wrong, exactly — but they're all silent, and silent conventions are exactly what breaks the moment someone else tries to read the CSV back, or tries to convert it back to JSON six months later.

Flattening nested objects: pick a separator, then be consistent

The standard approach for a nested object is dot-notation flattening: each level of nesting joins onto the column name with a separator.

{
  "name": "Ada Lovelace",
  "address": {
    "city": "London",
    "postcode": "SW1A 1AA"
  }
}

becomes three flat columns:

name,address.city,address.postcode
Ada Lovelace,London,SW1A 1AA

The separator itself (., _, or /) doesn't matter much on its own — what matters is that you use the same separator every time, and that whatever reads the CSV back into JSON knows which separator was used. A converter that lets you flatten with . today and expects _ on the way back will quietly produce the wrong nested structure, which is a much harder bug to spot than a crash.

Nested arrays: the decision most tools get wrong

Objects flatten cleanly because they have named keys. Arrays don't — and this is where "flatten JSON to CSV" tools genuinely diverge, because there are two legitimate approaches and no tool should silently pick one for you without saying so.

Index-expand. Each array item becomes its own numbered column set:

name,tags.0,tags.1,tags.2
Ada Lovelace,mathematician,writer,

This is great for short, roughly fixed-length arrays — tags, categories, a small list of phone numbers — because every item gets its own real spreadsheet column that's easy to filter and sort on.

Keep-as-JSON-text. The whole array stays as one JSON-encoded string in a single cell:

name,tags
Ada Lovelace,"[""mathematician"",""writer""]"

This preserves the array exactly — including its length — but you lose the ability to work with individual items as separate spreadsheet columns.

If your arrays vary a lot in length between records, index-expand will pad the shorter ones with empty (or null) trailing columns rather than telling you "this record only had two tags, not three." That's a structural limit of flattening arrays into columns at all, not a bug in any particular tool — if the exact length of a variable array matters to your downstream process, keep-as-JSON-text is the honest choice.

Neither option is objectively better. What matters is that the tool you use makes the choice visible and consistent, rather than burying it in a settings drawer or hard-coding one convention with no way to change it.

Custom delimiters: comma isn't universal

A plain comma is the default CSV delimiter, but it's not the only one you'll meet in practice:

Semicolon — common in locales where a comma is the decimal separator (much of continental Europe), so Excel and other spreadsheet tools there export semicolon-delimited files by default.
Tab (TSV) — a frequent choice for exports where field values themselves often contain commas.
Pipe (|) — common in older systems and log-style exports.

Whichever delimiter you use, the quoting rules (RFC 4180) still apply: any field containing the delimiter, a double quote, or a line break needs to be wrapped in quotes, with internal quotes doubled. A converter that lets you switch delimiters but forgets to re-check which characters now need quoting will produce CSV that looks fine until you open it in the one spreadsheet program that parses it strictly.

Going the other way: CSV to nested JSON, with real types

Converting CSV back to JSON has its own pitfalls, mostly because every CSV cell is, technically, just a string.

Type inference turns those strings back into real JSON types where it's safe to do so:

42, -3.5 → JSON numbers
true / false (any letter case) → JSON booleans
an empty cell → null (or an empty string, depending on your setting)

The classic trap is leading zeros. A postcode like "007" or a reference ID stored as text will silently become the number 7 if a converter blindly coerces every numeric-looking string — which is precisely the kind of quiet corruption that surfaces as a support ticket weeks later. A converter with real type inference protects leading-zero strings and gives you a "force all strings" override for cases where you don't want any coercion at all.

Nested-key reconstruction is simply flattening in reverse: an address.city column becomes a nested address object with a city key, and — if the array convention was index-expand — tags.0/tags.1 columns rebuild back into a tags array.

Round-trip fidelity: why the settings have to match on both sides

Put the two directions together and you get the real test of a JSON ↔ CSV tool: does JSON → CSV → JSON actually reproduce your original structure? This only works if the flatten and unflatten logic are literal inverses of each other — same separator, same array-handling choice, on both sides. If a tool's export and import conventions were built independently (or if you export from one tool and import with another that guesses differently), you'll get valid-looking JSON back that quietly doesn't match what you started with.

If you want to sanity-check the shape of your JSON before you flatten it — spotting an unexpectedly nested field, or validating that an API response is well-formed in the first place — a plain JSON formatter and validator is worth running first.

Try it: a converter built around round-trip fidelity

We built Skojio's JSON ↔ CSV Converter specifically to make the flatten/unflatten convention visible and symmetric instead of hidden. It supports:

Comma, semicolon, tab, pipe, or a custom delimiter, with correct RFC 4180 quoting on both read and write
A persistent, always-visible "Nested data" control for the separator and array strategy — the one setting that determines whether your round trip actually holds
Type inference on the CSV → JSON path, with leading-zero protection and a "force all strings" override
A one-click "Verify round-trip" action that sends your output straight back through the other direction, so you can see your original structure reappear

Everything runs in your browser — nothing you paste or upload is sent to a server. It's a genuinely useful complement to JSON Formatter for validating structure first, and to Base64 Encoder/Decoder if your JSON payload also needs encoding for a data URI or an API header along the way.

CSV is flat; JSON isn't — every JSON-to-CSV conversion has to make an explicit decision about how nesting becomes columns.
Nested objects flatten cleanly with a consistent separator; nested arrays need an explicit index-expand vs keep-as-JSON-text choice.
Custom delimiters (semicolon, tab, pipe) need the same RFC 4180 quoting rules as a plain comma.
Type inference on CSV → JSON must protect leading-zero strings from being coerced into numbers.
Round-trip fidelity only holds if the same separator and array-strategy settings are used on both sides of the conversion.

Chmod 755 vs 644 vs 777: What Linux File Permissions Actually Mean

Skojio Community — Tue, 07 Jul 2026 10:05:03 +0000

If you've ever pasted chmod 755 from a Stack Overflow answer without knowing why, or stared at rwxr-xr-x in an ls -l listing wondering what it's telling you, you're not alone. Linux file permissions are one of those things every developer touches constantly and understands properly only after getting burned once. This guide walks through what the numbers actually mean, when 755 is right and when 644 is right, why 777 keeps showing up in "quick fixes" that aren't actually fixes, and how to decode a permission string the moment you see one.

Each permission digit (0–7) is the sum of read (4), write (2), and execute (1)
644 — standard for regular files: owner can read/write, everyone else read-only
755 — standard for directories and scripts: owner has full access, everyone else can read and execute
777 — full access for everyone, almost never the correct answer
rwxr-xr-x is the symbolic spelling of the same permission set ls -l shows you — and it decodes to 755

How Octal Permission Numbers Work

Every Linux file or directory has three sets of permissions: one for the owner, one for the group, and one for everyone else. Each set is a single digit from 0 to 7, built by adding together the values of whichever permissions are switched on:

Value	Meaning
4	read
2	write
1	execute

So a digit of 7 means read + write + execute (4+2+1), 6 means read + write (4+2, no execute), 5 means read + execute (4+1, no write), and 0 means nothing at all. A three-digit permission like 755 is just three of these digits stacked: 7 for the owner, 5 for the group, 5 for everyone else.

A fourth, leading digit is optional and encodes the special bits — setuid, setgid, and the sticky bit — which we'll come back to further down.

Chmod 755 vs 644: When to Use Each

These two are by far the most common permission sets you'll ever set, and the difference between them is entirely the execute bit.

	Owner	Group	Other	Typical use
644	read, write	read	read	Regular files: HTML, CSS, images, config files, documents
755	read, write, execute	read, execute	read, execute	Directories, shell scripts, compiled binaries

As a rule of thumb: 644 for files, 755 for directories and anything meant to run. A directory needs its execute bit set just to be entered (cd) or listed properly — without it, even a directory you can "read" will behave strangely.

If a hosting support article tells you to "set permissions to 644", it means: the owner (usually your account or the web server user) can edit the file, and everyone else — including the web server process reading it to serve a page — can only view it. That's exactly right for a static file. Try to make that same file executable and nothing changes for how it's served; the execute bit is irrelevant to files a web server just reads and returns.

Why chmod 777 Is (Almost) Always the Wrong Answer

chmod 777 gives every user on the system — owner, group, and anyone else who can reach the file — full read, write, and execute access. On a shared server or anything reachable by a web process, that means any compromised script, any other user account, or any misconfigured process can read, overwrite, or execute that file freely.

The reason 777 shows up so often in forum "fixes" is that it genuinely does stop the permission-denied error — by removing every restriction, it removes the specific one that was actually the problem too. Almost always, the real fix is narrower: correcting file ownership (chown) so the right user owns the file, or fixing group membership so the process that needs access has it through the group permission instead of blowing the doors off for everyone. 750 or 770 — owner and group get full or read+execute access, "other" gets nothing — covers the overwhelming majority of cases people reach for 777 to solve.

Symbolic Notation: What Does rwxr-xr-x Mean?

ls -l doesn't show you octal digits — it shows you nine characters split into three groups of three, one group per owner/group/other:

rwxr-xr-x
└┬┘└┬┘└┬┘
owner group other

Each group is r, w, x if that permission is granted, or - if it isn't, always in that fixed order. So rwx is 7, r-x is 5, rw- is 6, and r-- is 4 — the same values from the octal table above, just spelled out instead of summed. rwxr-xr-x is therefore owner=7, group=5, other=5: octal 755. rw-r--r-- is 6, 4, 4: octal 644.

Reading Full ls -l Output

A real ls -l line carries more than just the permission string:

-rwxr-xr-x  1 alice staff  8192 Jun 30 09:14 deploy.sh

Breaking that down left to right:

- — the file type. - is a regular file, d is a directory, l is a symbolic link.
rwxr-xr-x — the nine-character permission string covered above (755 here).
1 — the hard-link count.
alice — the owning user.
staff — the owning group.
8192 — file size in bytes.
Jun 30 09:14 — last modified.
deploy.sh — the filename.

Once you know the shape, you can decode any ls -l line at a glance — or paste the whole line into a parser and let it do the arithmetic for you.

Setuid, Setgid, and the Sticky Bit — the Fourth Digit

Beyond the standard three digits, there's an optional fourth digit that sets three special behaviours: setuid (4) makes an executable run with its owner's privileges rather than the caller's; setgid (2) does the same for group identity and, on a directory, makes new files inherit that directory's group automatically; and the sticky bit (1) — used on shared directories like /tmp — means only a file's own owner (or root) can delete or rename it, even if everyone else can write there.

These show up in symbolic notation as a lowercase s or t replacing the execute character when the underlying execute bit is also on, or an uppercase S/T when it isn't (an unusual combination ls -l flags this way on purpose, since it's usually a mistake). It's a small enough detail that it's easier to see live than to memorise — worth playing with rather than reading about.

Try It Yourself

The fastest way to get comfortable with any of this is to stop doing the arithmetic in your head. Skojio's chmod calculator keeps the octal number, the symbolic string, and a checkbox grid all in sync as you edit any one of them, generates the exact chmod command to copy into a terminal, and — if you've got a real ls -l line or a bare permission string sitting in a hosting panel somewhere — parses it straight back into all three views so you can see exactly what it means before you touch it.

It runs entirely in your browser: nothing you type or paste is sent anywhere.

If permissions were the errand that brought you here, a few of Skojio's other free browser-based tools are worth a look too: the JSON Formatter for tidying up config and API output, the Base64 encoder/decoder for the other everyday encoding puzzle, and the Password Generator for the account-security half of "locking things down properly."

How to decode a Base64 string (4 reliable ways)

Skojio Community — Wed, 01 Jul 2026 13:19:06 +0000

You copied a blob of letters and numbers out of a config file, a JWT, or an API response, and you need to know what it actually says. It looks like gibberish — SGVsbG8sIHdvcmxkIQ== — but the trailing == gives it away: that's Base64, and it decodes back to plain text in seconds.

There are four reliable ways to decode it, depending on where you are and how awkward the string is. If you'd rather skip the command-line flags entirely, the Skojio Base64 decoder turns any string back into text or a downloadable file in one paste. Here's each method, and what to do when a string refuses to decode.

What a Base64 string actually is (and why it's not encryption)

Base64 is a binary-to-text encoding. It maps arbitrary bytes onto 64 printable ASCII characters — A–Z, a–z, 0–9, +, and / — so that binary data survives transport through systems that only accept text, like email headers, JSON fields, and URLs.

Every 3 bytes of input become 4 characters of output, which is why Base64 is always about 33% larger than the source. The = signs at the end are padding: they pad the final group up to a multiple of four characters when the input length doesn't divide evenly by three.

src="/blog/figures/base64-byte-mapping.jpg"
alt="The text 'Man' shown as three bytes, regrouped into four 6-bit chunks, and mapped to the Base64 characters T, W, F and u"
caption="Three bytes of text (24 bits) regroup into four 6-bit chunks — one Base64 character each."
/>

The critical point: Base64 has no key. It is trivially reversible by anyone, so it provides zero secrecy. A Base64-encoded password is a plaintext password with extra steps. Decoding it isn't decryption — it's just reading.

Because a Base64 string is plaintext, pasting one into a random online decoder hands your data to that server. If the blob is a JWT, an API response, or anything you'd treat as a credential, decode it locally — in the terminal, the browser console, or a client-side tool that never sends it over the network.

You'll meet Base64 most often in four places: data URIs (data:image/png;base64,… that inline an image straight into CSS or HTML), JWTs (whose header and payload are Base64url-encoded JSON), HTTP Basic Auth (the Authorization: Basic header is just base64(user:password)), and email attachments (MIME wraps binary parts in Base64). Recognising which one you're holding tells you what the decoded output should look like before you even run the command.

Decode a Base64 string in the terminal with `base64 --decode`

The fastest method on macOS and Linux is the built-in base64 command:

echo "SGVsbG8sIHdvcmxkIQ==" | base64 --decode
# → Hello, world!

src="/blog/figures/base64-terminal.jpg"
alt="A terminal showing 'echo SGVsbG8sIHdvcmxkIQ== | base64 --decode' returning 'Hello, world!', and the reverse encode command"
caption="Decoding and re-encoding 'Hello, world!' with the built-in base64 command."
/>

On older macOS the flag is capitalised:

echo "SGVsbG8sIHdvcmxkIQ==" | base64 -D

If the decoded output is binary (an image, a gzip blob), don't print it to the terminal — redirect it to a file instead:

echo "$B64" | base64 --decode > output.png

One terminal caveat: some PEM certificates and email payloads wrap Base64 at 64 characters per line. GNU base64 tolerates those newlines, but the BSD build on macOS can complain — pass -i to ignore non-alphabet characters, or strip the newlines with tr -d '\n' before piping.

On Windows, certutil or PowerShell do the same job:

[Text.Encoding]::UTF8.GetString([Convert]::FromBase64String("SGVsbG8="))

Decode Base64 in the browser console with `atob`

Already in DevTools? The browser ships a decoder: atob (ASCII-to-binary).

atob("SGVsbG8sIHdvcmxkIQ==");
// → "Hello, world!"

There's one sharp edge. atob returns a binary string, so any non-ASCII content — accented characters, emoji, anything UTF-8 — comes out mangled. The correct incantation for Unicode is:

new TextDecoder().decode(
  Uint8Array.from(atob(b64), (c) => c.charCodeAt(0))
);

If you find yourself reaching for that snippet more than once, paste the string into the Base64 tool instead — it handles UTF-8 correctly by default, so café and 🚀 round-trip without the TextDecoder dance.

Why your Base64 string won't decode — padding, URL-safe, and UTF-8

Most "invalid Base64" errors come down to three causes:

Missing padding. A valid Base64 string's length is a multiple of 4. If yours isn't, strict decoders reject it. Append = until the length divides by four — one or two signs is all it ever needs.
URL-safe variant. Base64url, used in JWTs and URL query strings, swaps + for - and / for _, and usually drops padding entirely. A standard decoder chokes on it. Convert - back to + and _ back to / first, then re-pad.
Stray whitespace. Strings copied from emails, certificates, or wrapped JSON often carry newlines or spaces. Strip them before decoding — most command-line tools fail on embedded whitespace even though the data is fine.

A JWT is the classic trap: it's three Base64url segments joined by dots. Split on the ., decode the first two segments, and you get the header and payload as JSON. The signature won't decode to anything readable — that's expected.

Data URIs hide a fourth gotcha. A string like data:image/png;base64,iVBORw0KGgo… isn't pure Base64 — the part you decode starts after the comma. Feed the whole data: prefix into a decoder and it fails; strip everything up to and including the comma first, then decode the remainder to recover the original file bytes.

If you only need to verify that a string is valid Base64 without caring about the output, check two things: the alphabet (only A–Z, a–z, 0–9, +, /, and trailing = for standard Base64) and the length-multiple-of-4 rule. Anything outside that alphabet means it's either URL-safe, corrupted, or not Base64 at all.

Decode any Base64 string in one paste

When the variant is ambiguous, the padding is missing, or the result is a file rather than text, stop fiddling with flags and paste it into a decoder that just works.

The Skojio Base64 encoder and decoder auto-detects standard and URL-safe input, fixes padding for you, decodes UTF-8 correctly, and lets you decode straight to a downloadable file for binary payloads. It runs entirely in your browser, so a JWT or an internal API token never leaves your machine — no upload, no account, no rate limit.

Recap

Where you are	How to decode
macOS / Linux terminal	`base64 --decode` (or `-D`)
Windows	`certutil -decode` or `FromBase64String`
Browser DevTools	`atob()` — wrap in `TextDecoder` for UTF-8
Awkward string, URL-safe, or a file	Skojio Base64 decoder

Base64 is an encoding, not a secret. Once you can read it on demand, the blob in your config file stops being mysterious — and when the next one resists base64 --decode, paste it into the decoder and let it sort the padding out for you.

What does a cron expression mean? Read it field by field

Skojio Community — Wed, 01 Jul 2026 13:19:05 +0000

Someone hands you 0 */2 * * 1-5 and asks "when does that run?" You can read the five fields, but the slash and the dash turn it into a small puzzle. Cron syntax is compact by design — five fields and four symbols cover almost every schedule you'll ever need — but compact means easy to misread.

The good news: a cron expression is fully decodable once you know what each field and symbol does. This guide reads one field by field. If you'd rather just paste an expression and see the answer in plain English, the Skojio cron expression helper translates it and lists the next 10 fire times instantly.

The five fields of a cron expression, left to right

A standard cron line is five space-separated fields followed by the command:

┌───────── minute        (0–59)
│ ┌─────── hour          (0–23)
│ │ ┌───── day-of-month  (1–31)
│ │ │ ┌─── month         (1–12 or JAN–DEC)
│ │ │ │ ┌─ day-of-week   (0–6 or SUN–SAT; 0 and 7 are both Sunday)
│ │ │ │ │
0 9 * * 1   /path/to/job.sh

Read positionally, never by name — cron doesn't label its fields, so 9 in the second slot is the hour, full stop. The example above means 09:00, on Mondays. Everything else is built from how each field is filled.

Count the fields first. Five means standard cron; six usually means a seconds field is bolted on the front (common in Quartz and some app schedulers). Misjudging which dialect you're in is the fastest way to read every field one position out.

How to read `*`, `,`, `-`, and `/` in any cron field

Four symbols do all the work, and they mean the same thing in every field:

* (asterisk) — every valid value. * in the hour field means every hour. * * * * * runs once a minute.
, (comma) — a list. 0,30 in minutes means "at 0 and at 30". 1,15 in day-of-month means the 1st and the 15th.
- (dash) — an inclusive range. 1-5 in day-of-week means Monday through Friday. 9-17 in hours means every hour from 9am to 5pm.
/ (slash) — a step. */15 in minutes means every 15th minute (0, 15, 30, 45). You can combine it with a range: 0-30/10 means minutes 0, 10, 20, 30.

The slash trips people up most. */15 is fixed clock positions, not an offset from when you saved the crontab — if you save at 14:07, the next run is 14:15, not 14:22. The same logic governs the three cron mistakes that break overnight jobs, so it's worth internalising early.

What `0 9 * * 1-5` means in plain English (worked example)

Take it field by field:

Field	Value	Reads as
minute	`0`	at minute 0
hour	`9`	of the 9th hour (09:00)
day-of-month	`*`	every day of the month
month	`*`	every month
day-of-week	`1-5`	Monday to Friday

Put together: 09:00 every weekday. A classic "send the morning report on business days" schedule.

src="/blog/figures/cron-anatomy.jpg"
alt="The cron expression 0 9 * * 1-5 broken into five labelled fields — minute, hour, day, month and weekday — reading as 09:00 Monday to Friday"
caption="Reading 0 9 * * 1-5 field by field: 09:00, Monday to Friday."
/>

Now read 0 */2 * * 1-5 the same way: minute 0, every 2nd hour (00:00, 02:00, 04:00 … 22:00), every weekday — so on the hour, every two hours, Monday to Friday. Reading positionally and resolving each symbol turns any expression into a sentence.

src="/blog/figures/cron-explain-terminal.jpg"
alt="A terminal translating the cron expression 0 */2 * * 1-5 into plain English: at minute 0, every 2nd hour, Monday through Friday"
caption="The same reading, automated: paste an expression, get a sentence and the next run times."
/>

One more that looks harmless but isn't: 0 0 1,15 * * means midnight on the 1st and 15th of every month — a list, not a range. Swap the comma for a dash and 0 0 1-15 * * becomes midnight on every day from the 1st to the 15th, which is fifteen runs a month instead of two. The single character is the entire difference, which is exactly why reading each symbol deliberately beats skimming.

Special strings and the optional sixth field

Many cron implementations accept named shortcuts that replace all five fields:

@hourly = 0 * * * *
@daily (or @midnight) = 0 0 * * *
@weekly = 0 0 * * 0
@monthly = 0 0 1 * *
@reboot = once, at daemon startup

You'll also see six-field expressions in the wild. Some schedulers (Quartz, Spring, many container cron images) prepend a seconds field, so */30 * * * * * means "every 30 seconds". If an expression has six fields and the first looks like a seconds step, that's why — count the fields before you read them, because a five-field parser will misread a six-field line entirely.

A couple of field-specific quirks are worth knowing too. Months and weekdays accept three-letter names: 0 0 * JAN MON is as valid as 0 0 * 1 1, and often clearer. Day-of-week is the field most likely to bite, because 0 and 7 both mean Sunday — so a range like 0-6 and 1-7 both cover the full week, just with the boundary in a different place. And ? shows up in Quartz-style expressions as a "no specific value" marker in the two day fields, used to sidestep the day-of-month-versus-day-of-week ambiguity that standard cron handles as an OR.

Read any cron expression in plain English

Reading by hand is a good skill, but the safest check before you ship a schedule is to confirm the next fire times match your intent.

The cron expression helper parses an expression, describes it in plain English, and lists the next 10 runs in your chosen timezone — which also catches the day-of-month-versus-day-of-week surprise that pure field-reading can miss. Because schedules drift across regions, pair it with the Skojio timezone helper when a job has to fire at a specific local time. Both run in your browser with no install.

Recap

Symbol	Meaning	Example
`*`	every value	`* * * * *` → every minute
`,`	list	`0,30` → at :00 and :30
`-`	inclusive range	`1-5` → Mon–Fri
`/`	step (fixed positions)	`*/15` → :00 :15 :30 :45

Five fields, four symbols, read left to right — that's the whole grammar. Once it's second nature you can decode most expressions at a glance, and when one looks ambiguous, drop it into the cron helper and let the next fire times confirm you read it right.

How to remove unused CSS and shrink your stylesheet

Skojio Community — Wed, 01 Jul 2026 13:18:34 +0000

A fresh Bootstrap build is roughly 200KB of CSS. A typical site uses maybe a tenth of it. The other 90% ships to every visitor, parses on every page load, and lingers in your bundle forever — styling components you deleted two redesigns ago.

Unused CSS is the quiet tax on your Core Web Vitals: bytes downloaded, parsed, and matched against the DOM for no reason. The good news is that most of it is findable in the browser you already have open, and removable without rewriting a line of markup. If you'd rather skip the diagnosis and just shrink the file you ship, the Skojio CSS cleaner strips comments, duplicate properties, and whitespace from any stylesheet in one paste — no upload, no build step.

Unused CSS comes in two forms: dead selectors (whole rules nothing matches) and redundant bytes inside the rules you keep.
The Chrome DevTools Coverage panel shows exactly how much of each stylesheet goes unused on a given page.
PurgeCSS removes dead selectors during a build — but it will strip classes your JavaScript adds at runtime unless you safelist them.
Minifying never deletes a rule; it only removes the bytes around the rules you keep.
You can shrink the stylesheet you ship — comments, duplicate properties, whitespace — entirely in your browser, no pipeline required.

Why unused CSS piles up in production

CSS only ever grows. Every framework you pull in, every component you ship, every A/B test you forget to clean up adds rules — and nothing in the normal workflow ever takes them back out.

Three habits do most of the damage:

Frameworks shipped whole. Bootstrap, Bulma, or an old Tailwind build without a configured content array all bundle thousands of utility classes you will never reference.
Components that outlive their markup. You delete the promo-banner component but leave its 40 lines of CSS behind, because nothing breaks when you don't.
Copy-pasted resets and vendor blocks. The same normalise rules, pasted into three stylesheets, then concatenated and minified together into one fat file.

It helps to split the waste into two kinds, because they have completely different fixes. One is a diagnosis problem — you have to work out which rules nothing uses. The other is a cleanup problem — the rules you keep are simply written with more bytes than they need.

src="/blog/figures/css-two-kinds-of-waste.jpg"
alt="A diagram splitting CSS waste into two rows: dead selectors, fixed with DevTools Coverage and PurgeCSS, and redundant bytes such as comments and duplicate properties, fixed by minifying"
caption="Dead selectors need a diagnosis tool; redundant bytes just need cleaning — and only the first needs a build step."
/>

Get the categories straight and the rest of the job is mechanical. Mixing them up is how people either ship a bloated file they think is clean, or delete a rule that turns out to matter.

How to find unused CSS in the Chrome DevTools Coverage panel

The browser ships the diagnosis tool. In Chrome or Edge, open DevTools, press Cmd+Shift+P (Ctrl+Shift+P on Windows) and run Show Coverage. Click the reload icon in the Coverage tab and interact with the page while it records.

Each stylesheet then gets a red-and-green bar. Green is bytes that matched something; red is bytes that never did. Click a file and the source view highlights the unused lines directly, so you can see which selectors are dead rather than just a percentage.

Coverage is per-page and per-interaction. It only marks a rule "used" if you actually triggered it — so open the modal, hover the dropdown, and visit the checkout before you trust the numbers. A rule that looks dead on the homepage may be the only thing styling a page you didn't click.

This is the right tool for measuring the problem, not fixing it. Coverage won't rewrite your files, and deleting by hand from a 5,000-line stylesheet is how regressions happen. Treat the panel as the audit that tells you whether the waste is worth chasing — if a stylesheet is 80% red, it is. Once you've confirmed there are real dead rules to remove, automate the removal rather than hand-editing.

Remove unused CSS in a build with PurgeCSS (and where it falls short)

The standard way to delete dead selectors automatically is PurgeCSS. It scans your markup and scripts for the class names and IDs you actually reference, then drops every rule whose selector never appears.

src="/blog/figures/css-purge-terminal.jpg"
alt="A terminal running purgecss against a 248KB stylesheet, which prints a new 31KB file after removing the dead rules"
caption="PurgeCSS scans your content for referenced selectors and rewrites the stylesheet without the dead rules."
/>

Run it against your built output and a Bootstrap-sized file routinely drops by 80–90%. Tailwind does the same thing natively now — its content array is a built-in purge step — which is why a modern Tailwind build is small even though the framework defines millions of possible utilities.

The catch is everything PurgeCSS can't see. It matches selectors as literal strings in your source, so any class name your code builds at runtime is invisible to it.

PurgeCSS strips classes added by JavaScript unless you safelist them. A line like el.classList.add('is-' + state) produces class names that appear nowhere in your source as literal text, so the matching rules get purged and the component renders unstyled in production — while looking perfect in dev, where you didn't run the purge. Add a safelist for any dynamically composed class before you trust the output.

So PurgeCSS handles dead selectors well, with a safelist as the price of admission. What it deliberately does not touch is the second kind of waste — the bytes inside the rules you're keeping.

Dead selectors are a diagnosis problem; redundant bytes are a cleanup problem — and only one of them needs a build step.

Shrink the CSS you keep — without a build pipeline

After the dead rules are gone, the file you ship is still padded with bytes that do nothing: developer comments, blank lines, four-space indentation, and duplicate declarations where the same property is set twice in one block. Minifying removes all of it without changing a single thing the browser renders.

You don't need a bundler to do this for a one-off stylesheet, a vendor file, or a snippet a designer handed you. Paste it into a client-side cleaner and get the minified version straight back. Skojio's CSS cleaner strips comments, collapses whitespace, removes duplicate properties within a block, and can sort declarations for a consistent diff — all in the browser, so the stylesheet never leaves your machine.

It won't hunt down dead selectors — that's the Coverage-and-PurgeCSS job above, because only your markup knows which rules are truly unused. But for squeezing the redundancy out of the CSS you've decided to keep, pasting the file into the cleaner is faster than wiring up a build for a file you'll process once, and it typically shaves 30–70% off the size before compression.

Recap

Kind of waste	How to remove it
Dead selectors (nothing matches)	Find with DevTools Coverage, remove with PurgeCSS
Classes added by JavaScript at runtime	Safelist them before purging
Comments, whitespace, duplicate properties	Minify and clean the stylesheet
A one-off file with no build set up	Paste into a client-side CSS cleaner

Find the dead rules in Coverage, prune them in your build, then run the file through the cleaner to squeeze out the bytes that are left. Most stylesheets come out a third smaller before you've touched a line of markup — and your visitors stop downloading two redesigns' worth of CSS they'll never see.

Schedule a meeting across time zones without the guesswork

Skojio Community — Wed, 01 Jul 2026 13:18:33 +0000

"Let's do 3pm." Whose 3pm? Yours, the colleague in San Francisco who is still asleep, or the client in Sydney for whom it is already tomorrow? A surprising share of the calendar invites that land an hour wrong start with exactly that sentence.

Coordinating a call across continents is a solved problem — you just need to see everyone's working hours at once instead of doing offset arithmetic in your head. If you'd rather skip the maths entirely, the Skojio timezone helper stacks every participant's zone on one 24-hour timeline, marks where the working days overlap, and hands you a link to share the exact slot.

Most scheduling errors come from doing UTC-offset arithmetic by hand — and from forgetting that offsets change with daylight saving.
The fastest way to pick a slot is visual: stack everyone's working hours on one timeline and look for the overlap.
Communicate times in UTC, written as ISO 8601 with an offset, so there is never a "your time or mine?".
Pin recurring meetings to a named zone like Europe/London, not a fixed UTC time, so they follow daylight-saving shifts.
Time-zone drift breaks scheduled jobs the same way it breaks meetings.

Why scheduling across time zones goes wrong

The trap is assuming the gap between two cities is a fixed number. It is not. London and New York are five hours apart for most of the year — but for roughly two weeks each spring and autumn, when one region has changed its clocks and the other has not, the gap is four hours. Every "always five hours apart" rule of thumb is wrong twice a year.

Three things compound it:

Bare local times. "3pm" carries no zone. The moment it leaves your calendar and lands in an email, half the recipients silently assume it means their 3pm.
The date line. When it is 9am Monday in California, it is already 2am Tuesday in Sydney. Mental arithmetic that ignores the day rollover books people for the wrong date, not just the wrong hour.
The wrong canonical reference. Teams store "the meeting time" as whatever the organiser's clock said, so when the organiser travels or their region shifts, the stored time moves with them.

Get those three straight and the rest is mechanical. Ignore them and you generate a steady trickle of missed calls that everyone blames on "time zones" rather than on arithmetic.

How to find a meeting time that works in every time zone

Stop converting in your head. The reliable method is visual: take each participant's working hours — say 09:00 to 17:00 local — translate them onto one shared axis, and look for the column where the bands overlap.

Worked example. A call between London, New York, and São Paulo:

London (UTC+1 in summer): 09:00–17:00 local is 08:00–16:00 UTC.
New York (UTC−4): 09:00–17:00 local is 13:00–21:00 UTC.
São Paulo (UTC−3): 09:00–17:00 local is 12:00–20:00 UTC.

The only window all three share is 13:00–16:00 UTC — early afternoon in London, mid-morning in New York and São Paulo. Any slot in that band is inside everyone's working day.

src="/blog/figures/timezones-overlap.jpg"
alt="Three stacked 24-hour timelines for London, New York and São Paulo with each city's nine-to-five band shaded, and the 13:00 to 16:00 UTC overlap highlighted"
caption="Stack each city's working hours on one UTC axis and the shared window is obvious — here, 13:00–16:00 UTC."
/>

Rather than work that out by hand, drop each city onto the timeline and read the overlap straight off the grid. When the zones are far enough apart that no band overlaps — San Francisco and Sydney, classically — there is no good answer, only a least-bad one. Seeing that on screen is the point: it tells you to rotate the awkward slot between teams instead of always burdening the same people.

Anchor on whoever has the narrowest availability. If one person observes a school run or a hard 18:00 stop, their constraint defines the window — fit everyone else around it rather than finding a slot that suits the majority and quietly excludes them.

Store and share times in UTC and ISO 8601

Pick one canonical reference for every stored timestamp, and make it UTC. Convert to local only at the moment you display it. That single rule removes a whole category of bug, because the stored value never depends on where anyone happens to be sitting.

When you write a time down for a human, use ISO 8601 with an explicit offset: 2026-06-10T15:00:00+01:00. It is unambiguous, sorts correctly as text, and every calendar app parses it.

src="/blog/figures/timezones-date-terminal.jpg"
alt="A terminal rendering one UTC instant, 14:00 UTC, in London, New York and Sydney using the date command with the TZ variable, showing 15:00 BST, 10:00 EDT and midnight the next day in Sydney"
caption="One instant in UTC, rendered in three zones — note the DST-correct abbreviations and Sydney's date rollover."
/>

For sharing, the rule is the same: never write a bare "3pm" and hope. Send the ISO timestamp, or a link that renders the slot in each person's local zone so nobody has to count. The same drift that derails meetings also derails automation — a scheduled task set in the wrong zone fires at the wrong hour — which is exactly why the cron expression helper shows fire times in a zone you choose rather than guessing the server's.

Daylight saving: the shift that breaks recurring calls

Daylight saving is where "I'll just remember the offset" finally collapses. Regions switch on different weekends, the southern hemisphere runs opposite to the northern, and places like most of Arizona or the entire UTC-anchored server fleet never switch at all. The offset between any two of them is a moving target.

An offset is a fact about a moment, not a property of a city — and it changes twice a year.

The costliest version is the recurring meeting. Book a weekly call as a fixed UTC time and it will drift by an hour for half the attendees the next time a clock changes — they show up early or late for weeks until someone notices.

Pin recurring events to a named IANA zone (Europe/London, America/New_York), never to a fixed UTC offset. A calendar that knows the zone applies each daylight-saving transition automatically; one that only knows "+01:00" freezes that offset and silently shifts the call for everyone the moment the rules change.

Compare any time zones in one screen

When a call spans three or more zones, stop converting in your head and put them all on one timeline.

Skojio's timezone helper lays every zone on a single 24-hour grid, stays accurate through daylight saving by using live zone data, lets you drag the time to find a slot, and gives you a shareable link that opens in each colleague's own local time. It runs entirely in your browser — no account, no calendar permissions, nothing uploaded.

Recap

Problem	Fix
Ambiguous "3pm"	Attach a zone, or send ISO 8601 with the offset
Offset arithmetic by hand	Stack zones on one timeline and read the overlap
Recurring call drifts at DST	Pin the event to a named zone, not a fixed UTC offset
No shared working hours	Rotate the awkward slot; share a link so no one miscounts

Time zones are only hard when you do them in your head. Line the zones up on one screen, agree the slot in UTC, and share it as a link — the next "whose 3pm?" thread never gets started.

DEV Community: Skojio Community

Verifying a JWT Signature: HS256 vs RS256 (and What exp Actually Means)

What a JWT actually is: three segments, not one blob

Reading the standard claims: what exp, iat, nbf, aud, iss actually mean

Decode first, verify second — and why the order matters

Verifying HS256: the shared-secret family

Verifying RS256 and ES256: the public/private-key family

Two JWT security traps worth knowing by name

Try it: decode, verify, and build test tokens in one page

Funny Passphrases: Easy to Remember, Hard to Guess

Why a random passphrase generator beats a character-soup password

"Correct horse battery staple": the diceware idea, explained

When funny beats plain: the memorability trick

Numbers, symbols, and separators — do they matter?

Password vs passphrase: which should you use?

Try it yourself

How to Convert SOAP XML to JSON (and Back) Without Losing Attributes or Namespaces

Why SOAP and WSDL interop keeps needing this conversion

XML attributes to JSON: the @-prefix convention

Element text, and when it needs a #text key

Namespaces: keep the prefix, or strip it deliberately

XML arrays to JSON: repeated elements, not a fixed schema

Going the other way: JSON to XML online, correctly

Round-trip fidelity: why the settings have to be shared, not duplicated

Try it: an XML ↔ JSON converter built around round-trip fidelity

AGENTS.md, Explained: One File for Claude, Cursor, Copilot and Windsurf

What AGENTS.md actually is

Why you still end up with five files

The fix for CLAUDE.md: bridge, don't duplicate

Converting Cursor rules to AGENTS.md (and the glob caveat)

.cursorrules and .windsurfrules are deprecated — read them, don't write them

Doing it without hand-copying

99.9% Uptime: How Much Downtime Is That, Really? (Plus Combined SLA)

What Does 99.9% Uptime Actually Mean?

The Nines, From One to Six

How to Convert an Outage Into an Uptime Percentage

Combined SLA for Dependent Services: Why You Can't Just Average

Comparing Vendor SLAs Side by Side

Try It Yourself

How to Generate TypeScript Types from JSON (Without Getting Optional Fields Wrong)

What "generate TypeScript types from JSON" actually means

The single-sample problem: why optional fields go missing

What correct multi-sample merging looks like

Handling JSON to TypeScript nested objects

Other details worth checking before you trust a converter's output

Try it: a json to typescript converter built around correct merging

How to Flatten Nested JSON to CSV (and Convert It Back Without Losing Data)

Why nested JSON breaks naive CSV export

Flattening nested objects: pick a separator, then be consistent

Nested arrays: the decision most tools get wrong

Custom delimiters: comma isn't universal

Going the other way: CSV to nested JSON, with real types

Round-trip fidelity: why the settings have to match on both sides

Try it: a converter built around round-trip fidelity

Chmod 755 vs 644 vs 777: What Linux File Permissions Actually Mean

How Octal Permission Numbers Work

Chmod 755 vs 644: When to Use Each

Why chmod 777 Is (Almost) Always the Wrong Answer

Symbolic Notation: What Does rwxr-xr-x Mean?

Reading Full ls -l Output

Setuid, Setgid, and the Sticky Bit — the Fourth Digit

Try It Yourself

How to decode a Base64 string (4 reliable ways)

What a Base64 string actually is (and why it's not encryption)

Decode a Base64 string in the terminal with base64 --decode

Decode Base64 in the browser console with atob

Why your Base64 string won't decode — padding, URL-safe, and UTF-8

Decode any Base64 string in one paste

Recap

What does a cron expression mean? Read it field by field

The five fields of a cron expression, left to right

How to read *, ,, -, and / in any cron field

What 0 9 * * 1-5 means in plain English (worked example)

Special strings and the optional sixth field

Read any cron expression in plain English

Recap

How to remove unused CSS and shrink your stylesheet

Why unused CSS piles up in production

How to find unused CSS in the Chrome DevTools Coverage panel

Remove unused CSS in a build with PurgeCSS (and where it falls short)

XML attributes to JSON: the `@`-prefix convention

Element text, and when it needs a `#text` key

Decode a Base64 string in the terminal with `base64 --decode`

Decode Base64 in the browser console with `atob`

How to read `*`, `,`, `-`, and `/` in any cron field

What `0 9 * * 1-5` means in plain English (worked example)