I want to start with the decision that shaped everything else.

When I started building TextlyPop, a collection of 35+ free text tools, I had a choice. Build it the normal way with a backend that processes text server-side, or run everything client-side in JavaScript so the text never touches a server at all.

I chose client-side. Every single tool. No exceptions.

That one decision changed the entire architecture of the project and I want to walk through exactly how it works, what problems it created, and how I solved them.

Why client-side only

The tools people use most on a site like this handle sensitive content. Password generators. JSON formatters with API keys inside. Word counters processing private client briefs. Reading level checkers on unpublished drafts.

None of that should go through someone else's server. Not because I would do anything with it, but because users should not have to trust me not to. The safest architecture is one where the data physically cannot leave the device, not one where I promise it does not.

So the rule was simple. If a tool can run in JavaScript, it runs in JavaScript. The only thing PHP handles is the shared header, footer, and the central tool registry. Everything that touches user text is pure client-side.

The architecture

The folder structure is straightforward:
public/

├── index.php

├── about.php

├── sitemap.php

├── includes/

│ ├── header.php

│ ├── footer.php

│ └── functions.php

├── assets/

│ ├── css/style.css

│ └── js/main.js

└── tools/

├── word-counter.php

├── json-formatter.php

└── ... (35+ tools)

PHP does three things only. It includes the shared header and footer on every page. It reads from a central get_all_tools() function in functions.php to build the homepage grid, the sitemap, the footer navigation, and the related tools section. And it outputs the static HTML shell of each tool page.

JavaScript does everything else. Every tool is self-contained in its own script block inside the tool PHP file. No framework, no build step, no npm. Vanilla JS throughout.

The central tool registry

This was the most important structural decision after the client-side rule.

Every tool is registered once in functions.php as a simple array:

[
    'slug'     => 'json-formatter',
    'name'     => 'JSON Formatter',
    'desc'     => 'Format and validate JSON instantly.',
    'category' => 'format',
    'keywords' => ['json formatter','json validator','format json'],
],

That single registration feeds everything automatically. The homepage tool grid. The category filter buttons. The sitemap.xml via a dynamic sitemap.php. The footer navigation. The related tools section on every tool page. The search functionality.

Add one block to functions.php and the new tool appears everywhere simultaneously. No manual sitemap updates, no editing the homepage, nothing else to touch.

localStorage auto-save

Every textarea on every tool has a data-save-key attribute. A single event listener in main.js watches all textareas and saves their content to localStorage under that key on every keystroke.

document.querySelectorAll('textarea[data-save-key]').forEach(function(el) {
    var key = 'tp-' + el.dataset.saveKey;
    el.value = localStorage.getItem(key) || '';
    el.addEventListener('input', function() {
        localStorage.setItem(key, el.value);
    });
});

When you come back to a tool your text is exactly where you left it. No server, no account, no database. Just the browser remembering your session.

The send-to system

This is the feature I am most proud of technically even though it sounds simple.

Every tool page has Send to buttons at the bottom. Clicking one takes the output of the current tool and preloads it into another tool as input. The implementation is one function in main.js:

document.querySelectorAll('.send-to-btn[data-from][data-to-tool]').forEach(function(btn) {
    btn.addEventListener('click', function() {
        var sourceEl = document.getElementById(btn.dataset.from);
        if (!sourceEl || !sourceEl.value.trim()) return;
        var targetSlug = btn.dataset.toTool;
        localStorage.setItem('tp-send-' + targetSlug, sourceEl.value);
        window.location.href = '/tools/' + targetSlug;
    });
});

On the receiving tool page, on load, it checks localStorage for a pending send:

function receiveSentText() {
    var meta = document.querySelector('meta[name="tool-slug"]');
    if (!meta) return;
    var key = 'tp-send-' + meta.content;
    var sent = localStorage.getItem(key);
    if (!sent) return;
    localStorage.removeItem(key);
    var target = document.querySelector('textarea[data-save-key]');
    if (target) {
        target.value = sent;
        target.dispatchEvent(new Event('input'));
    }
}

The result is that tools chain together naturally. Convert case, send to word counter, send to reading level checker. Your text flows through the workflow without touching the clipboard once.

The SEO stack

Every tool page has four JSON-LD schema blocks. WebApplication, FAQPage, HowTo, and BreadcrumbList. All generated in PHP so they are consistent across all 35+ pages without manual repetition.

The sitemap is dynamic PHP that reads from get_all_tools() and outputs valid XML with proper lastmod dates. Adding a new tool to the registry automatically adds it to the sitemap on the next Google crawl.

One thing I got wrong initially that cost me indexing time. I had header('X-Robots-Tag: noindex') on sitemap.php. Google was fetching the sitemap URL and then refusing to process it because of that header. Removing it was the single most important crawlability fix I made.

What I would do differently

Three things I underestimated going in.

First, the word list problem. Two tools use static embedded word lists for offline operation. A static list of even 3000 words has gaps that real users find immediately. The rhyme finder now uses the Datamuse API which solved it cleanly.

Second, the send-to system needs a sessionStorage fallback. localStorage persists across sessions which means if you accidentally navigate away you can end up with stale data preloading into a tool unexpectedly.

Third, I should have set up the CDN on day one rather than after launch. Flushing cache after every file update is now a permanent part of my deploy workflow and I wish I had built that habit from the beginning.

The stack in one line

PHP 8.2 for includes and routing. Vanilla JavaScript for all tool logic. One CSS file. One JS file. No framework. No build step. No npm. No backend that touches user text. Hosted on Hostinger LiteSpeed with a CDN layer on top.

TextlyPop is live at textlypop.com. 35+ tools, free forever, and your text stays on your device.

If you have questions about any of the implementation decisions I made, drop them in the comments. Genuinely happy to go deeper on anything here.

And if there is a text tool you keep needing and cannot find a clean free version of, tell me. That is exactly how most of the tools on the site got built.