DEV Community: TextKit

I Built 40 Free Browser-Based Tools with Flask and No JavaScript Framework

TextKit — Sat, 07 Mar 2026 02:35:54 +0000

No React. No Next.js. No build step. No node_modules.

I built TextKit — a collection of 40 free online tools for text processing, data cleaning, and developer utilities — using Flask, Tailwind CSS via CDN, and vanilla JavaScript. The entire project starts with python app.py.

Here's the stack, the architecture decisions, and what I've learned.

The stack

Python + Flask       → serves HTML via Jinja2 templates
Tailwind CSS CDN     → styling, zero build config
Vanilla JavaScript   → all tool logic, 100% client-side
Markdown + YAML      → blog system
Render               → hosting
Cloudflare           → DNS + caching
Umami                → privacy-friendly analytics

No database. No auth system. No npm. The entire deployment is a Flask app serving static-ish pages.

Why no framework?

Because these tools don't need one.

A JSON formatter takes text input, calls JSON.parse() and JSON.stringify(), and displays the result. A password generator calls crypto.getRandomValues() and builds a string. A diff checker runs an LCS algorithm on two arrays of strings.

Every single tool follows the same pattern: input → transform → output. A <textarea>, an addEventListener('input', ...), and a function. React adds a virtual DOM, a component lifecycle, a build system, and 40KB of JavaScript to do the same thing that 20 lines of vanilla JS handles.

I'm not anti-framework. I use React at work. But for this project, a framework would have been overhead with zero user benefit.

Architecture

Every tool is a Jinja2 template that extends base.html:

templates/
  base.html                     → nav, footer, fonts, theme CSS
  index.html                    → homepage with search + tool grid
  tools/
    json-formatter.html         → extends base.html
    password-generator.html     → extends base.html
    regex-tester.html           → extends base.html
    ... (40 tools)

The Flask app is dead simple:

@app.route('/json-formatter')
def json_formatter():
    return render_template('tools/json-formatter.html')

One route per tool. The TOOLS registry is a list of dicts that drives the homepage grid, sitemap, and navigation. Add a tool to the list, it shows up everywhere.

All logic is client-side

Hard rule from day one: no text data goes to the server. Ever.

Users paste sensitive stuff into text tools — API keys, database queries, internal emails, customer data. If any of that hits a server, you've created a trust and liability problem. Everything runs in the browser, and users can verify this by disconnecting from the internet — every tool still works.

For most tools this is trivial. But a few pushed the limits:

Diff Checker — implements a full Longest Common Subsequence algorithm with character-level highlighting within changed lines. The LCS matrix is O(m×n) which means comparing two 5,000-line texts creates a 25 million cell array. Works, but I added a warning for large inputs.

Regex Tester — runs user-supplied patterns via new RegExp(). Zero-length matches like \b cause infinite loops in the exec() loop if you don't handle them:

while ((match = regex.exec(text)) !== null) {
  matches.push(match);
  if (match[0].length === 0) regex.lastIndex++;  // prevents infinite loop
}

CSV Parser — you might think parsing CSV is text.split(','). It's not. Real-world CSV has quoted fields with commas inside, escaped quotes (double-quote within a quoted field), and newlines within quoted fields. The parser is a proper state machine.

Time Zone Converter — uses the browser's Intl.DateTimeFormat API for all timezone calculations. No timezone library, no database file. Modern browsers know every IANA timezone and handle DST automatically.

The tool list

40 tools across 9 categories:

Delimiter tools (10): Column↔Comma, Column↔Tab, Column↔Semicolon, Column↔Pipe, Column↔Space — all bidirectional

Text transform (5): Case Converter, Trim Whitespace, Add Prefix/Suffix, Number Lines, Slug Generator

Data cleaning (3): Remove Duplicates, Remove Blank Lines, Sort Lines

Text analysis (2): Word Counter, Count Lines

Text extraction (4): Extract Emails, URLs, Numbers, Phone Numbers

Generators (3): Password Generator, UUID Generator, Lorem Ipsum Generator

Developer tools (5): JSON Formatter, Regex Tester, Diff Checker, Epoch Converter, Time Zone Converter

Encode/Decode (3): Base64, URL Encode/Decode, Text to Binary

Data formats (2): CSV to JSON, JSON to CSV

SEO as architecture

Each tool page has:

Unique title and meta description targeting specific search keywords
200+ word "what is this tool" section
FAQ section with <details>/<summary> tags
FAQPage schema markup (JSON-LD) — earns rich snippets in Google
WebApplication schema
Related tools section with internal cross-links
Canonical URL and OpenGraph tags

The SEO content is roughly 70% of each page. The tool itself is a textarea and some buttons. Google ranks pages for informational queries, and the tool functionality keeps users engaged and builds backlinks organically.

I also run a blog with Markdown files parsed via a simple Flask route. Each post targets a "how to" keyword and links to the relevant tool. The blog posts rank for informational queries, drive traffic, and pass internal link authority to the tool pages.

What I'd do differently

Build the high-traffic tools first. I started with delimiter converters because they were simple. But JSON Formatter (350K monthly searches) and Password Generator (450K monthly searches) should have been first — more search volume, earlier indexing.

Don't use Tailwind CDN in production. It works and it's zero-config, but it loads the entire Tailwind stylesheet (~300KB). Self-hosting a purged CSS file would be much smaller. Haven't gotten around to it.

SEO content takes longer than building tools. Writing the "what is" sections, FAQs, and schema markup for 40 tools took more hours than writing the JavaScript. Plan for that.

Current status

40 tools live
12 blog posts
Indexed and ranking in Google (averaging position 20 and climbing)
Thermal receipt theme — because developer tools should have personality

Everything is free, no accounts, no tracking. Check it out: textkit.dev

Happy to answer questions about the stack, the SEO approach, or any of the tool implementations.

Regex Cheat Sheet: 10 Patterns That Handle 90% of Real Work

TextKit — Thu, 05 Mar 2026 11:45:38 +0000

I've been writing regex for years and I still look things up constantly. The problem with most cheat sheets is they list every possible syntax token without telling you which ones you'll actually use.

Below are my working references, the patterns I reach for over and over.

The six characters you need to know

\d  →  any digit (0-9)
\w  →  any word character (letter, digit, underscore)
\s  →  any whitespace (space, tab, newline)
\D  →  any NON-digit
\W  →  any NON-word character
\S  →  any NON-whitespace

Uppercase = inverse. That's the whole pattern.

Quantifiers

+      one or more
*      zero or more
?      zero or one (optional)
{3}    exactly 3
{2,5}  between 2 and 5
{3,}   3 or more

The * vs + distinction matters: \d* matches an empty string (zero digits is fine). \d+ requires at least one digit. When in doubt, you want +.

The 10 patterns I copy-paste the most

1. Email

[\w.-]+@[\w.-]+\.\w{2,}

Not RFC-perfect. Doesn't need to be. Handles real-world emails.

const emails = text.match(/[\w.-]+@[\w.-]+\.\w{2,}/g);

2. URLs

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

The s? makes "s" optional; it catches both http and https.

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

3. US phone numbers

\(?\d{3}\)?[-.\s]?\d{3}[-.\s]?\d{4}

Handles 123-456-7890, (123) 456-7890, 123.456.7890, and 1234567890.

4. IP addresses (IPv4)

\b\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}\b

The \b word boundaries are important. Without them you'd match numbers inside longer strings.

5. Dates (YYYY-MM-DD)

\d{4}-(?:0[1-9]|1[0-2])-(?:0[1-9]|[12]\d|3[01])

Validates format and checks month is 01-12, day is 01-31.

6. Hex colors

#(?:[0-9a-fA-F]{3}){1,2}\b

Matches both short #fff and long #ff00aa format.

7. Everything between double quotes

"([^"]*)"

The capture group ([^"]*) grabs the content. [^"]* means "any character except a quote, zero or more times."

8. Whole word match

\bword\b

\b is the word boundary anchor. \bcat\b matches "cat" but not "catch" or "concatenate".

9. Numbers with optional decimals

-?\d+\.?\d*

Matches 42, 3.14, -7, -0.5.

10. Multiple whitespace (for cleanup)

\s{2,}

Find two or more consecutive whitespace characters. Replace with a single space.

const clean = text.replace(/\s{2,}/g, ' ');

The three mistakes I see constantly

1. Not escaping periods. . matches ANY character. \. matches an actual period. This one bites everyone at some point.

2. Greedy vs lazy. ".*" on the string "hello" and "world" matches "hello" and "world", basically everything from first quote to last. Use ".*?" to match shortest: "hello" and "world" separately.

3. Forgetting the g flag. Without it, you only get the first match. Add g for global.

// Only first match
'abc 123 def 456'.match(/\d+/)    // ["123"]

// All matches
'abc 123 def 456'.match(/\d+/g)   // ["123", "456"]

Try it live

I built a regex tester with real-time match highlighting and a built-in cheat sheet. Paste a pattern, paste some text, see matches instantly. Runs in-browser, nothing stored.

Full version of this cheat sheet with lookahead/lookbehind and more examples: textkit.dev/blog/regex-cheat-sheet-beginners