DEV Community: Muhammad Umair | DevOmniTools

Why your cURL command works in terminal but fails in Python (4 gotchas that wasted my afternoon)

Muhammad Umair | DevOmniTools — Tue, 29 Sep 2026 09:10:00 +0000

We've all been there: you open Chrome DevTools, click Copy as cURL, paste it into your terminal, and it works like a charm.

Then you rewrite it into Python requests or httpx, hit run, and suddenly:

HTTP 400 Bad Request
{"error": "Malformed JSON payload"}

Or worse, a silent HTTP 403 Forbidden.

I spent an hour yesterday debugging an internal webhook call that worked in bash but kept failing in our automated runner. Here are the 4 subtle edge-cases where translating cURL to Python breaks—and how to fix them.

1. The Trailing Slash & Automated Redirect Trap

When you run this in terminal:

curl -X POST https://api.example.com/v1/auth -d '{"user":"test"}'

If the endpoint expects https://api.example.com/v1/auth/ (with a trailing slash), modern curl silently follows or handles it depending on server config.

In Python:

# ❌ Silently drops POST body if server returns a 301/308 redirect!
r = requests.post("https://api.example.com/v1/auth", json={"user": "test"})

By default, standard requests.post() will follow a 301/302 redirect by downgrading the method to GET and dropping the payload entirely!

Fix: Always verify whether the server enforces a trailing slash. If you need automatic redirect preservation, use a Session or inspect r.history.

2. Double-Encoded JSON String vs. Raw Dict

In curl, people often write:

curl -X POST https://api.example.com/data \
  -H "Content-Type: application/json" \
  -d '{"items": [1, 2, 3], "active": true}'

When porting to Python, junior devs often do this:

# ❌ Double-stringification trap
import json
import requests

payload = json.dumps({"items": [1, 2, 3], "active": True})
requests.post(url, json=payload)

Notice the mistake? Passing json=json.dumps(...) serializes the string twice. The server receives a string literal instead of a JSON object.

Rule of thumb:

Use json=my_dict (requests handles serialization and headers for you).
OR use data=json.dumps(my_dict) with explicit headers={'Content-Type': 'application/json'}. Never mix both.

3. The Pseudo-Headers Copied from Chrome

When you click "Copy as cURL" from browser DevTools, Chrome copies everything, including HTTP/2 pseudo-headers:

curl 'https://service.com/api' \
  -H 'sec-ch-ua: "Chromium";v="128"' \
  -H 'sec-fetch-dest: empty' \
  -H 'sec-fetch-mode: cors' \
  -H 'sec-fetch-site: same-origin' \
  -H 'Accept-Encoding: gzip, deflate, br, zstd'

If you blindly paste all those headers into Python:

Some WAFs (like Cloudflare or Akamai) detect that the TLS fingerprint does NOT match a real browser Chrome TLS handshake, and they flag the request as a spoofed bot.
If Accept-Encoding: br (Brotli) or zstd is sent, Python's requests library cannot decode it natively unless you have brotli installed, leaving you with raw binary gibberish in r.text.

Fix: Strip out browser-specific sec-ch-* headers and let Python handle encoding headers naturally. Keep only Authorization, Content-Type, and your custom headers.

4. Escaped Quotes in Bash Shells

If your curl payload contains shell variables or nested quotes:

curl -d "{\"title\": \"John's Report\"}" https://api.com

Bash string escaping rules differ wildly from Python string escaping. Unescaping backslashes by hand on a 50-line payload is a recipe for syntax errors.

How I Handle This Now

After hitting these gotchas one too many times during staging tests, I stopped doing manual string surgery.

If you just want clean Python Requests code without spending 15 minutes stripping pseudo-headers and fixing JSON quotes, you can drop your curl command into this in-browser converter:
👉 DevOmniTools cURL to Python & Fetch Converter

It runs 100% in your local browser memory (zero server uploads, so no private API tokens leak into cloud logs) and cleans up the headers automatically.

Hope this saves someone a headache next time a "working" cURL command refuses to run in production scripts!

How to Decode & Inspect X.509 SSL Certificates and CSRs Without OpenSSL (or Leaking Data to Unknown Servers)

Muhammad Umair | DevOmniTools — Mon, 28 Sep 2026 08:10:49 +0000

A few months back, I was helping migrate an internal API gateway to a fresh Kubernetes cluster. It was late on a Friday afternoon. We generated a new Certificate Signing Request (CSR), submitted it to our enterprise CA, wired up the issued certificate to the Ingress controller, and were immediately greeted by this lovely browser screen:

NET::ERR_CERT_COMMON_NAME_INVALID

Why? Because whoever generated the CSR forgot to include the wildcard subdomain in the Subject Alternative Names (SANs) list.

When you hit a roadblock like that, you usually have two choices:

Fire up a terminal and fight with OpenSSL CLI flags (openssl req -in request.csr -noout -text | grep -A 2 "Subject Alternative Name").
Or open a browser, Google "parse csr online", and paste your PEM block into the first result on Google.

Most people do #2. But here is the problem: pasting internal certificates and CSRs into random websites is an operational security hazard waiting to happen.

The Silent Problem with Online "Certificate Checkers"

Even if your certificate only contains public keys, your certificate metadata is far from harmless.

When you paste a certificate or CSR into an online decoder, three things often happen behind the scenes:

1. Internal Network Topology Leakage

Subject Alternative Names (SANs) don't just secure example.com. In enterprise environments, they almost always list internal hostnames and infrastructure endpoints:

auth-internal.stg.corp.net
k8s-control-plane.vpn.company.internal
vault-cluster-01.eu-west-1.private

The moment you click "Decode" on a server-rendered tool, that domain topology travels over an HTTP POST request, passes through a remote reverse proxy, and sits indefinitely in third-party access logs or APM traces (Datadog, CloudWatch, etc.).

2. The "Accidental Private Key" Disaster

How many times have you opened a combined .pem bundle that contained both the certificate chain and the private key?
If someone blindly copies that buffer and hits "Paste" into an online tool that runs server-side parsing, that private key just left your perimeter.

3. Server-Side Execution Overhead

Most online utilities are just thin wrappers: an Express or Flask backend that takes your string, writes it to a temporary file in /tmp/cert.pem, runs openssl x509 -text -noout, and pipes the stdout back as JSON. If that server gets compromised, every certificate ever submitted is sitting in temporary storage or shell history.

What Actually Is an X.509 Certificate?

To understand how to inspect certificates safely, you have to understand how they are built under the hood.

An X.509 certificate is not text. It is an ASN.1 (Abstract Syntax Notation One) data structure serialized into a compact binary format called DER (Distinguished Encoding Rules), and then wrapped in Base64 with ASCII boundary headers to create a PEM file:

   ## What Actually Is an X.509 Certificate?

To understand how to inspect certificates safely, you have to understand how they are built under the hood.

An X.509 certificate is **not text**. It is an **ASN.1 (Abstract Syntax Notation One)** data structure serialized into a compact binary format called **DER (Distinguished Encoding Rules)**, and then wrapped in Base64 with ASCII boundary headers to create a **PEM file**:

text
+--------------------------------------------------------+
| PEM File (.crt) |
| -----BEGIN CERTIFICATE----- |
| MIID0zCCA3igAwIBAgIRANUJklyNsQ4ZE6Ohyxx7BaswCgYIK... |
| -----END CERTIFICATE----- |
+--------------------------+-----------------------------+
| 1. Strip headers & Base64 decode
v
+--------------------------------------------------------+
| Binary DER Stream |
| [0x30, 0x82, 0x03, 0xD3, 0x30, 0x82, 0x02, ...] |
+--------------------------+-----------------------------+
| 2. Walk Tag-Length-Value (TLV)
v
+--------------------------------------------------------+
| Parsed Certificate Tree |
| |-- Version: v3 (0x02) |
| |-- Serial Number: 0d:51:92:5c:8d:b1:0e... |
| |-- Signature Algorithm: ecdsa-with-SHA256 |
| |-- Issuer: CN=WE1, O=Google Trust Services, C=US |
| |-- Validity Period: |
| | |-- Not Before: 2026-09-05 22:29:39 UTC |
| | |-- Not After: 2026-12-04 23:29:33 UTC |
| |-- Subject: CN=cloudflare.com |
| |-- Extensions: |
| |-- Subject Alternative Names (SANs): |
| |-- DNS: cloudflare.com |
| |-- DNS: *.cloudflare.com |
| |-- DNS: *.secondary.cloudflare.com |
+--------------------------------------------------------+


---

## How ASN.1 Tag-Length-Value (TLV) Works in Practice

Every element in a binary DER stream is structured ## How ASN.1 Tag-Length-Value (TLV) Works in Practice

Every element in a binary DER stream is structured as a **Tag-Length-Value (TLV)** triplet:

1. **Tag (1 Byte):** Tells the parser what type of data is coming up:
   - `0x30`: SEQUENCE (a container holding other fields)
   - `0x02`: INTEGER (serial numbers, version numbers)
   - `0x03`: BIT STRING (public keys, digital signatures)
   - `0x06`: OBJECT IDENTIFIER (OID, e.g. `2.5.4.3` for Common Name)
   - `0x13` / `0x0C`: PrintableString / UTF8String (human-readable names)
   - `0x17` / `0x18`: UTCTime / GeneralizedTime (expiration dates)

2. **Length:**
   - If length is < 128 bytes: The length is stored directly in a single byte (`0x00` to `0x7F`).
   - If length is >= 128 bytes: The highest bit is set (`0x80`). The first byte tells you how many subsequent bytes hold the length value (e.g. `0x82` means the next two bytes represent the length).

3. **Value:** The raw payload bytes.

### Decoding DER Bytes in Browser Memory (TypeScript)

Here is how you can strip PEM armor and parse the raw binary DER bytes entirely in-memory:

typescript
// 1. Strip ASCII PEM boundaries and whitespace
export function pemToBinary(pem: string): Uint8Array {
const base64 = pem
.replace(/-----BEGIN [^-]+-----/g, '')
.replace(/-----END [^-]+-----/g, '')
.replace(/\s+/g, '');

const rawString = atob(base64);
const bytes = new Uint8Array(rawString.length);
for (let i = 0; i < rawString.length; i++) {
bytes[i] = rawString.charCodeAt(i);
}
return bytes;
}

typescript
// 2. Recursive Tag-Length-Value (TLV) walker
export interface ASN1Node {
tag: number;
length: number;
headerLen: number;
raw: Uint8Array;
children: ASN1Node[];
}

export function parseASN1(bytes: Uint8Array, offset = 0): ASN1Node {
const tag = bytes[offset];
let lenByte = bytes[offset + 1];
let length = 0;
let headerLen = 2;

// Multi-byte length handler
if (lenByte & 0x80) {
const numBytes = lenByte & 0x7f;
headerLen += numBytes;
for (let i = 0; i < numBytes; i++) {
length = (length << 8) | bytes[offset + 2 + i];
}
} else {
length = lenByte;
}

const raw = bytes.slice(offset + headerLen, offset + headerLen + length);
const node: ASN1Node = { tag, length, headerLen, raw, children: [] };

// If this node is a SEQUENCE (0x30), unpack its nested children
if (tag === 0x30) {
let childOffset = offset + headerLen;
const end = childOffset + length;
while (childOffset < end) {
const child = parseASN1(bytes, childOffset);
node.children.push(child);
childOffset += child.headerLen + child.length;
}
}

return node;
}


---

## Extracting What Really Matters: SANs & Fingerprints

### 1. Subject Alternative Names (SANs) ## Extracting What Really Matters: SANs & Fingerprints

### 1. Subject Alternative Names (SANs) - OID `2.5.29.17`
Since RFC 2818, browsers completely ignore the `Common Name (CN)` for hostname validation. Only the **Subject Alternative Names (SANs)** extension matters.

In ASN.1 DER, each SAN entry has a context-specific tag:
- Tag `0x82` = `dNSName` (e.g. `*.example.com`)
- Tag `0x87` = `iPAddress` (e.g. `192.168.1.1`)

typescript
export function extractSANs(sanExtensionRaw: Uint8Array): string[] {
const sans: string[] = [];
const sequence = parseASN1(sanExtensionRaw);

for (const item of sequence.children) {
// 0x82 is context tag [2] for dNSName
if (item.tag === 0x82) {
sans.push(new TextDecoder().decode(item.raw));
}
}
return sans;
}


### 2. Computing SHA-256 Fingerprints in the Browser
You don't need OpenSSL to compute a certificate fingerprint. The native browser **W3C Web Cryptography API (`crypto.subtle`)** computes it with hardware acceleration in milliseconds:

typescript
export async function getFingerprint(derBytes: Uint8Array): Promise {
const hashBuffer = await crypto.subtle.digest('SHA-256', derBytes);
return Array.from(new Uint8Array(hashBuffer))
.map(byte => byte.toString(16).padStart(2, '0'))
.join(':')
.toUpperCase();
}

This produces the exact same fingerprint string as running:

bash
openssl x509 -noout -fingerprint -sha256 -in cert.crt




---

## The Zero-Exfiltration Approach: Inspecting Offline

Because remembering OpenSSL syntax is tedious when you are trying to resolve an outage quickly, we built an entirely client-side inspection tool:

## The Zero-Exfiltration Approach: Inspecting Offline

Because remembering OpenSSL syntax is tedious when you are trying to resolve an outage quickly, we built an entirely client-side inspection tool:

**[DevOmniTools X.509 Certificate & CSR Decoder](https://www.devomnitools.com/en/tools/x509-certificate-decoder/)**

### Why we built it this way:
1. **Zero Network Traffic:** The parser runs 100% inside your browser's local JavaScript execution engine. You can literally disconnect your Wi-Fi or turn on Airplane Mode, and it parses full X.509 certs and CSRs instantaneously.
2. **Immediate Expiration Calculation:** Live calculation showing whether a certificate is active, expiring soon, or already past its `Not After` date.
3. **Full CSR Parsing:** Inspect public keys, signature algorithms, and SANs in a `.csr` *before* paying a Certificate Authority or waiting hours for a re-issuance.
4. **Air-Gapped Friendly:** Built for engineers on restricted VPNs or secure networks where sending data to random external servers is strictly forbidden by policy.

If you want to read our full deep-dive on offline certificate inspection algorithms and RFC standards, check out the engineering guide:  
**[How to Decode X.509 Certificates Offline - Comprehensive Specification](https://www.devomnitools.com/en/solutions/decode-x509-certificate-offline/)**

---

## Quick Reference Cheat Sheet

| Task | OpenSSL CLI Command | DevOmniTools Equivalent |
|---|---|---|
| **View Expiration Dates** | `openssl x509 -noout -dates -in cert.crt` | Instant countdown badge & validity panel |
| **Check SANs** | `openssl x509 -noout -text -in cert.crt \| grep -A 2 "Subject Alternative Name"` | Dedicated SANs tag list |
| **Inspect a CSR** | `openssl req -noout -text -verify -in req.csr` | Paste `.csr` PEM directly into decoder |
| **SHA-256 Fingerprint** | `openssl x509 -noout -fingerprint -sha256 -in cert.crt` | Hardware WebCrypto SHA-256 hash |

---

How does your team handle certificate and CSR validation before deploying to staging or production? Have you ever had an outage caused by an expired cert or a missing SAN? Let me know in the comments!

How to Convert SVGs into Clean Web Icon Fonts Entirely in the Browser (No Node, No Canvas, No Server Uploads)

Muhammad Umair | DevOmniTools — Sat, 26 Sep 2026 12:05:56 +0000

A while back I needed a custom icon font for a side project. Nothing fancy — maybe 30 icons, all SVGs I had already exported from Figma. The "proper" way to do this is apparently to install some Node toolchain, run a CLI, and hope the output isn't garbage. I didn't want any of that. My whole app runs client-side, so why should the font pipeline need a server?

Turns out, you can build a real, valid TTF icon font in pure browser JavaScript. No canvas, no Node, no uploading your SVGs to someone's server. This post walks through exactly how I did it, with working code.

If you're in a hurry, I ended up polishing the whole thing into a tool you can use right now: devomnitools.com/en/tools/svg-to-font/. But stick around if you want to know how it actually works under the hood — it's less magic than you'd think.

Why bother with icon fonts at all in 2026?

Fair question. SVG sprites and inline SVGs are great, and for most cases I'd reach for those first. But icon fonts still win in a few specific situations:

You need legacy / standalone embedded icon support
You're theming via color and font-size — with icon fonts, currentColor just works, no CSS variables gymnastics
Huge icon sets where inline SVGs would bloat your HTML DOM for no reason

Also, honestly, it's just a fun engineering problem to solve.

The two libraries that make this possible

Everything hinges on two battle-tested libraries:

svgpath — parses SVG path data (d attributes) and lets you transform it mathematically.
opentype.js — a full font compiler that runs directly in JavaScript. It can build fonts from scratch, not just read them.

That's it. No canvas needed, because we never rasterize anything — a font glyph is vector data, so the conversion is mostly just moving numbers around.

Step 1: Get clean path data from your SVGs

The first gotcha: an icon font only understands path outlines. Your SVG might contain <circle>, <rect>, <line>, strokes with round caps — a font glyph has none of that vocabulary. Everything must be a single filled path (or a few paths combined).

If you're exporting from Figma/Illustrator/Inkscape, use "Outline Stroke" before export. In Figma it's Shift + Ctrl/Cmd + O. Do this before exporting, and 90% of your pain disappears.

Then, in the browser, read the file and extract all <path> elements:

async function svgToPathData(file) {
  const text = await file.text();
  const doc = new DOMParser().parseFromString(text, "image/svg+xml");
  const paths = [...doc.querySelectorAll("path")]
    .map(p => p.getAttribute("d"))
    .filter(Boolean);

  if (paths.length === 0) {
    throw new Error(`${file.name}: no <path> elements found. Outline your strokes first!`);
  }

  return paths.join(" "); // multiple subpaths are fine in one glyph
}

Heads up: If your SVG has transforms on the paths (transform="rotate(...)" etc.), you need to apply them to the path data or your icons will come out rotated/skewed. The svgpath library can do this, but cleaning up in your vector editor beforehand is usually less debugging.

Step 2: Normalize everything to the em square

Fonts are drawn on an em square — typically 1000 units tall for TTFs. Your SVGs have their own random viewBox, maybe 24x24, maybe 48x48. If you skip this step, every glyph will be a different size and your icons will look misaligned.

So for each icon: read the viewBox, compute the scale factor, and resize with svgpath:

import svgpath from "https://esm.sh/svgpath";

const EM_SIZE = 1000;

function normalizePath(d, viewBox) {
  const [,, vbW, vbH] = viewBox;
  const scale = EM_SIZE / Math.max(vbW, vbH);

  return svgpath(d)
    .scale(scale)
    .translate(0, EM_SIZE)
    .scale(1, -1) // flip Y to font coordinate space
    .round(2)
    .toString();
}

One thing that bit me: SVG's Y-axis points down, but font coordinates point up! For a 24-unit viewBox mapped to a 1000-unit em, you flip with .translate(0, EM_SIZE).scale(1, -1). If your icons render upside down (they will the first time), that's why!

Step 3: Build glyphs and compile the font

Now the fun part. opentype.js lets you define glyphs as path strings and compiles a valid TTF:

import opentype from "https://esm.sh/opentype.js";

function buildFont(icons) {
  // icons = [{ name: "home", pathData: "M0 0L..." }, ...]
  const notdef = new opentype.Glyph({
    name: ".notdef",
    unicode: 0,
    advanceWidth: EM_SIZE,
    path: new opentype.Path(),
  });

  const glyphs = icons.map((icon, i) => {
    const codepoint = 0xE000 + i; // Private Use Area — no emoji conflicts
    return new opentype.Glyph({
      name: icon.name,
      unicode: codepoint,
      advanceWidth: EM_SIZE,
      path: opentype.Path.fromSVG(icon.pathData),
    });
  });

  const font = new opentype.Font({
    familyName: "MyIcons",
    styleName: "Regular",
    unitsPerEm: EM_SIZE,
    ascender: EM_SIZE * 0.8,
    descender: -(EM_SIZE * 0.2),
    glyphs: [notdef, ...glyphs],
  });

  return font; // font.toArrayBuffer() gives you raw TTF bytes
}

Download it directly in the browser as a Blob:

function downloadFont(font) {
  const buffer = font.toArrayBuffer();
  const blob = new Blob([buffer], { type: "font/ttf" });
  const url = URL.createObjectURL(blob);
  const a = Object.assign(document.createElement("a"), {
    href: url,
    download: "my-icons.ttf",
  });
  a.click();
  URL.revokeObjectURL(url);
}

Step 4: Actually use the font with generated CSS

Generate a tiny CSS file alongside the TTF, mapping each icon to its Unicode codepoint:

function generateCss(icons) {
  const rules = icons.map((icon, i) => {
    const code = (0xE000 + i).toString(16).toUpperCase();
    return `.icon-${icon.name}:before { content: "\\${code}"; }`;
  });

  return `
@font-face {
  font-family: "MyIcons";
  src: url("my-icons.ttf") format("truetype");
  font-weight: normal;
  font-style: normal;
}

[class^="icon-"]:before, [class*=" icon-"]:before {
  font-family: "MyIcons";
  display: inline-block;
  speak: never; /* don't let screen readers read out codepoints */
}

${rules.join("\n")}`;
}

Then in HTML it's just:

<i class="icon-home"></i>
<i class="icon-settings" style="font-size: 24px; color: rebeccapurple;"></i>

Where this approach falls short (being honest)

No auto-hinting: Dedicated desktop font tools hint glyphs for tiny render sizes. For icons inside modern high-DPI displays this rarely matters, but text fonts would suffer.
Compound paths: Overlapping paths with fill-rule="evenodd" can render unexpectedly in some legacy renderers. Always test your exported icons.
WOFF2 output: Not built into opentype.js — you get TTF and WOFF. For most icon sets, TTF + WOFF is plenty for browser usage.
No advanced font mastering: Kerning tables, ligatures, variable axes are out of scope. It's an icon font, not Helvetica!

TL;DR

Export SVGs with strokes outlined.
Parse with DOMParser, extract d attributes.
Normalize to a 1000-unit em square with svgpath (and flip the Y axis!).
Compile with opentype.js glyphs.
Download as a blob, ship with a generated CSS file.

The whole pipeline is under 150 lines of vanilla JavaScript.

If you'd rather skip the plumbing and just get a font, my finished version handles multi-file upload, naming, live glyph preview, and CSS generation — it's free and everything stays in your browser with zero server data leakage:
👉 devomnitools.com/en/tools/svg-to-font/

Have you built anything with opentype.js? I keep finding new uses for it — font subsetting in the browser is probably my next rabbit hole. Let me know in the comments what you'd build!

Stop Pasting Your JWT Tokens Into Random Websites — I Built a Safer Alternative

Muhammad Umair | DevOmniTools — Tue, 15 Sep 2026 16:29:28 +0000

Every developer uses online utilities daily:

JSON formatters, JWT decoders, SQL beautifiers, Base64 encoders, regex testers, and password generators.

But there's a dirty secret hiding behind most of these "free" online tools: your sensitive data is being sent to a remote backend server every single time you hit that format button.

Your JWT token with its payload claims? Logged. Your proprietary SQL schema? Stored. Your AES encryption key? Sent over the wire.

That frustration became the foundation of DevOmniTools — 56+ developer utilities where zero bytes of your sensitive data ever leave your browser.

🚨 The Problem: Your Data Is Not as Safe as You Think
Privacy Problem — Traditional Tools vs DevOmniTools

Most developers don't think twice about pasting a JWT token, a database connection string, or an API key into an online formatter. But the backend of these sites receives and often logs every request.

Consider what you're actually exposing:

JWT tokens → contain user identity, roles, expiry claims
SQL queries → reveal your database schema and table structures
AES keys and salts → the literal secrets protecting your encrypted data
Bcrypt hashes → password verification data
The fix isn't to stop using tools. The fix is to use tools that never touch a server.

⚡ The Architecture: 100% Client-Side Execution
Tech Stack Architecture

Every single tool in DevOmniTools runs entirely within the browser's local sandbox using native browser APIs:

🔐 Security & Cryptography
Tool Browser API Used
AES-256-GCM Encrypt/Decrypt SubtleCrypto (Web Crypto API)
Bcrypt Hash Generator Client-side WASM bcrypt
JWT Decoder & Inspector Local Base64 parsing
SHA-256 / SHA-512 Hashing SubtleCrypto.digest()
HMAC Generator SubtleCrypto.sign()
Not a single byte of your keys, tokens, or hashes reaches our servers. Because we don't have any.

💻 Data & Schema Converters
SQL Formatter (PostgreSQL, MySQL, SQLite, IBM Db2) — Client-side AST parser
JSON ↔ YAML ↔ XML — In-browser bidirectional parsers
JSON to TypeScript — Recursive interface inference, all local
SQL to JSON/CSV — Multi-row INSERT parser, no backend
🎨 Design & Vector Tools
SVG to PNG Rasterizer — HTML5 Canvas with up to 8K print quality
CSS Glassmorphism Generator — Pure visual builder
CSS Flexbox Playground — Interactive drag stage, exports Tailwind tokens
Color Contrast Checker — WCAG AAA / APCA compliance, all local
🛠️ Why Astro? The Performance Decision
When I chose the framework for this project, the requirements were clear:

Zero unnecessary JavaScript for non-interactive pages
Sub-100ms Time to Interactive for tool pages
Static HTML output for maximum CDN cacheability
Astro delivers all three. It generates pure static HTML at build time and ships zero JavaScript to pages that don't need it. For tool pages, only the minimum interactive script ships — no framework runtime overhead.

Framework: Astro 7 (Static Site Generation)
Styling: Tailwind CSS 4
Computation: Web Workers (heavy tasks off main thread)
Crypto: SubtleCrypto (Web Crypto API)
Testing: Vitest — 440+ unit tests
Hosting: Cloudflare Pages (global edge network)
The result: tools that respond in milliseconds, not seconds.

🌍 Multilingual From Day One
Developer tools are used globally. DevOmniTools launched with 4 complete locales:

🇺🇸 English → devomnitools.com/en/
🇸🇦 Arabic (RTL) → devomnitools.com/ar/
🇪🇸 Spanish → devomnitools.com/es/
🇩🇪 German → devomnitools.com/de/
Every tool — its UI, meta descriptions, error messages, and SEO tags — is fully translated. Not just the landing pages, but the actual utility interfaces themselves.

Building RTL (Right-to-Left) support properly in Astro was one of the most interesting challenges. Arabic layout flipping for a complex multi-panel tool UI requires careful CSS logical properties usage throughout.

✅ Quality: 440+ Automated Tests
Before any tool ships, it must pass its full test suite.

With 56 tools across 4 locales, that's a lot of surface area for edge cases. Vitest runs the full suite on every commit, covering:

Parser accuracy (malformed JSON, nested YAML, multi-dialect SQL)
Crypto correctness (known-good vectors for AES, SHA, HMAC)
Unicode handling (Arabic, German umlauts, special characters)
Edge inputs (empty strings, deeply nested structures, large files)
442 tests. 442 passed. Every time.

🚀 What's Live Right Now
56+ production tools across these categories:

Security & Cryptography: AES-256-GCM, Bcrypt, JWT Decoder, SHA Hashing, HMAC, Password Entropy Tester, CSP Builder, X.509 Certificate Decoder, JWT Signature Verifier

Data & Code: JSON Formatter, YAML↔JSON, SQL Formatter, XML Inspector, JSON→TypeScript, SQL→JSON/CSV, Markdown→HTML, Markdown Table Generator, Code Minifier, Base64 Encoder/Decoder

Design & Visual: QR Code Generator, SVG Rasterizer, Flexbox Playground, Glassmorphism Generator, Clip-Path Generator, Color Contrast Checker, Color Converter

DevOps & Infra: Cron Builder, Docker Compose Generator, Docker Run→Compose Converter, Docker Compose→K8s Converter, Regex Tester

Generators & Calculators: UUID Generator, Loan EMI Calculator, Unix Timestamp Converter, Prompt Token Counter

💬 I'd Love Your Feedback
The platform is completely free and open for the community:

🔗 Live Site: https://devomnitools.com ⭐ Community Repo: github.com/contactumairrana/omnitools-community

A few questions for the community:

Which utility do you reach for most often in your daily workflow?
Any tool or format converter you wish existed but can't find a trustworthy client-side version of?
RTL developers — what specific challenges have you faced with developer tools lacking Arabic/RTL support?
Drop your answers below! Every piece of feedback directly shapes the next tool that gets built. 🚀

Built with Astro, deployed on Cloudflare Pages, tested with Vitest. No backend. No tracking. No cookies. Just tools.

Why I built 56+ Developer Tools that run 100% Client-Side (Zero Server Logs)

Muhammad Umair | DevOmniTools — Tue, 15 Sep 2026 15:57:44 +0000

Every developer uses online utilities daily: JSON formatters, JWT decoders, SQL beautifiers, regex testers, and base64 encoders.

However, a serious issue persists across most popular utility sites: your data gets sent to a remote backend server.

Whether it's an authorization bearer token, a proprietary database schema, or client configuration secrets, pasting sensitive data into third-party web tools is an unnecessary security hazard.

That is why I set out to build DevOmniTools — a comprehensive suite of 56+ developer tools where zero bytes of sensitive data leave your browser.

🛠️ The Architecture: 100% In-Browser Execution

To ensure absolute privacy and sub-millisecond responsiveness, every tool relies entirely on local browser primitives:

Security & Cryptography:
- JWT Inspector: Decodes headers and claims instantly in the client sandbox with a live token expiration countdown timer.
- AES-256-GCM & Bcrypt: Uses the native SubtleCrypto (Web Crypto API) and client-side salt hashing.
- Hashing: MD5, SHA-1, SHA-256, and SHA-512 calculated locally via Web Workers.
Data & Schema Conversions:
- SQL Formatter & Converters: Multi-dialect SQL formatter (PostgreSQL, MySQL, SQLite, Db2) and SQL-to-JSON/CSV converters that run entirely via client-side AST parsers.
- JSON / YAML / XML: Real-time bi-directional syntax validators and converters.
Design & Vector Suite:
- SVG to Vector Rasterizer: High-multiplier (up to 8K print quality) rendering using HTML5 Canvas sandboxes.
- CSS Glassmorphism & Flexbox Playground: Live interactive stage exporting pure CSS and Tailwind tokens.

⚡ Tech Stack & Performance Decisions

Framework: Astro — generates pure static HTML with zero unnecessary runtime JavaScript overhead for non-interactive content.
Styling: Modern Tailwind CSS with dark-mode first contrast.
Client Execution: Web Workers for heavy computational jobs (encryption/large file parsing) to keep the main thread fluid at 60 FPS.
Testing: 440+ automated unit tests powered by Vitest to guarantee parser accuracy.

🌐 Community & Open Source

We also maintain an open community repository where developers can contribute new tool ideas or inspect the ecosystem architecture:
👉 GitHub Community Repository

Check out the live platform here:
👉 https://devomnitools.com

I'd love your feedback:

Which utility tool do you find yourself needing most frequently in your daily workflow?
Any specific tool or format you'd like to see added next?

Drop your thoughts and feature requests below! 🚀

I built 45+ Free Developer Utilities with 100% Client-Side Privacy (Zero Server Logging)

Muhammad Umair | DevOmniTools — Sat, 12 Sep 2026 11:04:37 +0000

⚡ UPDATE: We are officially LIVE on Product Hunt today! If you find DevOmniTools helpful, please support our Product Hunt Launch 🚀

Why I Built OmniTools

Like most software engineers, I spend countless hours every week doing mundane developer tasks:

Formatting messy JSON payloads
Decoding and inspecting JWT authentication tokens
Converting SVG icons to PNG bitmaps
Testing regular expressions
Generating secure bcrypt hashes or AES-256 encrypted strings
Prototyping CSS Flexbox and Grid layouts

Whenever you Google for these tools, 95% of the results lead to ad-cluttered websites that send your sensitive data to backend servers, log query strings, or sell telemetry. If you work with production customer data or API secrets, this is an unacceptable security risk.

To solve this for myself and the engineering community, I built OmniTools (devomnitools.com) — a suite of 45+ modern, blazing-fast developer utilities designed with a strict Zero-Telemetry, 100% Client-Side Architecture.

🔒 The Zero-Server Guarantee

OmniTools runs entirely in your local browser sandbox:

Native Web Cryptography API: AES-256-GCM, SHA-256/512, and Bcrypt hashing run on hardware-accelerated local cryptographic modules.
HTML5 Canvas & Web Workers: File conversions (SVG to PNG, Base64 encoding, Image compression) occur in offline memory threads without sending a single byte over the wire.
PWA & Offline Capable: Built as an installable Progressive Web App with service-worker asset caching. You can disconnect your internet or use it mid-flight.
Zero Ads & Zero Cookies: Clean, distraction-free UI with dark/light themes and 4 language localizations (English, Spanish, German, and Arabic with native RTL).

🛠️ Key Utilities Available Today

Here are a few highlights out of the 45+ tools currently available:

Category	Featured Tools
🎨 Design & CSS	CSS Flexbox Visual Playground (with instant Tailwind code export), 8K SVG to PNG Rasterizer, Glassmorphism Generator, QR Code Studio (with custom logo overlay).
📊 Data & Formats	SQL INSERT to JSON/CSV Converter (with interactive data grid), JSON to TypeScript Type Generator, YAML/XML Bi-directional Converter, Markdown Live Preview.
🔐 Security & Crypto	AES-256-GCM Encryptor/Decryptor, Bcrypt Salt Hasher & Verifier, JWT Expiration & Claims Inspector, Password Entropy Calculator.
🌐 Web & Network	cURL to Fetch/Python Converter, CIDR IPv4/IPv6 Subnet Calculator, RFC 9110 HTTP Status Inspector, Meta Tag SEO Previewer.

🌟 Community & Open Roadmap

OmniTools is built for the global developer ecosystem. You can browse the complete tool catalog, file feature requests, or report bugs in our public community repository:

👉 Live Production App: https://www.devomnitools.com

👉 Community Repository: https://github.com/contactumairrana/omnitools-community

I would love to hear your feedback, thoughts on UI/performance, and what utilities you'd like to see added next! Let's build the ultimate developer Swiss Army knife together. 🚀