Running Kokoro in WordPress: generate in the admin tab, serve a saved file

Vladimir Grigoryan — Wed, 21 Oct 2026 09:00:25 +0000

A browser TTS demo usually ends when the audio starts playing. For a WordPress article, that's only part of the job. The recording also needs to survive the tab closing, stay attached to the right post, and keep working for readers on phones.

The approach I use is to generate the audio in the site owner's admin browser and save a file in WordPress. Readers then play that file. They never need to load the speech model.

The flow looks like this:

Saved post
  -> text prepared for speech
  -> Kokoro in the admin browser
  -> audio samples
  -> encode an audio file
  -> upload to WordPress
  -> Media Library attachment
  -> article player

Kokoro produces audio; MP3 encoding is a separate step. The kokoro-js examples save WAV files. If your publishing workflow needs MP3, include an encoder rather than changing the filename extension.

There are three things I'd decide before wiring up the player.

First, what exactly gets read? A post can contain headings, captions, code, tables, and embeds. Stripping all the HTML won't tell you whether a table makes sense when spoken. Show the prepared text or a report of skipped sections, then listen to a representative post before recording an archive. Names and abbreviations deserve a check too.

Second, where does the work happen? Keep inference in the admin screen. WordPress already handles the post, the user's permissions, and media storage. It doesn't need to run the speech model in this design. But this also means recording depends on the owner's machine and the browser tab staying open. It isn't an overnight server job.

The kokoro-js README documents WebAssembly and WebGPU backends and recommends fp32 for WebGPU. Test the path you actually ship on the hardware you expect people to use. A short sample can tell you whether generation works; an estimate extrapolated from it isn't a measured recording time for a long article.

Third, what happens after an edit? An attachment ID alone doesn't tell you whether the recording matches the current post. I'd keep a record shaped something like this, with illustrative values:

{
  "post_id": 123,
  "attachment_id": 456,
  "spoken_text_hash": "hash-of-the-prepared-text",
  "voice": "af_heart",
  "backend": "webgpu",
  "dtype": "fp32"
}

Hash the text you actually send to the model. When that text changes, mark the recording as out of date. Keep the previous audio available until its replacement has been uploaded successfully. A failed upload shouldn't remove the version readers can already play.

WordPress's Media REST API supports creating an attachment and associating it with a post. An admin integration also needs authenticated requests and permission checks. Once the file is stored, the public page can use an ordinary audio player. Keep the inference runtime out of that page's bundle.

There's also a privacy detail worth spelling out: local speech generation means the text can be processed without sending it to a TTS provider. Your WordPress host still stores the post, receives the recording, and serves it to readers. The initial model download needs a connection, and a browser cache can be cleared.

Before calling the workflow finished, I'd test a short post, a post with a table or code block, an interrupted recording, a failed upload, and an edit after recording. Then open the published article on a different device. That checks the handoff from generation to playback, which a browser demo by itself doesn't cover.

References: kokoro-js usage and backends, WordPress Media REST API.

I used AI assistance to draft and edit this article.

How to record a browser demo without exposing API keys

Vladimir Grigoryan — Tue, 20 Oct 2026 14:03:06 +0000

A demo often passes through a settings page on the way to the feature you want to explain. That page might contain a deploy token, an account email or a customer record. The audience doesn't need those details, but the recorder will capture them anyway.

Preparing the account before recording makes the final review much easier. Here's a practical workflow for a browser walkthrough.

We make Nixel, a Chrome extension for covering sensitive text on web pages. I'll use it as an example below, including where it needs a manual check.

Start with fictional values

Use a separate demo account when you can. Give it sample records and remove unrelated conversations, billing details and customer data.

If the walkthrough only needs to explain the shape of a request, use an unmistakably fictional value such as YOUR_DEMO_API_KEY. Don't paste a working credential into the example just to make the screen look realistic.

Walk through the route before pressing Record

Open each page, menu and expanded panel you plan to show. Check the settings screen, account menu, notification area and any place where you copy a request or response.

Include the transitions in this rehearsal. A value that is covered on the final screen may have been visible for a moment while a panel opened.

Prepare the view you will capture

Choose the browser tab or window needed for the demo. Close unrelated tabs and panels. If the walkthrough moves into a terminal, desktop editor or another application, prepare that view separately.

For credentials that must remain on the page, use an opaque cover and check that it spans the whole value. Inspect the first and last characters, and look for repeated copies elsewhere on the page. Treat any automatic detector's findings as a starting point for that review.

An example with Nixel

Open Nixel on the Chrome page you plan to record. Review the supported API keys, tokens and other sensitive text it detects, then choose solid bars or labels for the values that need to stay hidden. Detection runs on your device.

Check the page again after opening menus or moving to another screen. Nixel can miss values and doesn't cover your whole desktop, other apps or browser controls. Don't rely on it to detect text inside images or videos.

The before-and-after screenshot uses a fictional dashboard, so none of the example credentials are real.

If you want to try the same workflow, Nixel is available here:
https://chromewebstore.google.com/detail/nixel/mhdpmmbcnoakhpaemgpnomjpgklbdapk

Record a short test

Make a short recording that includes opening settings, expanding a panel and switching between the pages you need. Play the recorded file back at a readable size.

Check what the recorder actually captured, including the edges of the window and any account menus. This is also a chance to spot an awkward crop or a browser control you didn't mean to show.

Review the exported file

After the full take, watch the exact exported video you intend to upload. Check the moments when pages load, settings open and recording stops. Pause where a sensitive value might have appeared.

If you find an exposed credential, remove that section or record it again before sharing. Check that the file you upload is the reviewed export, rather than an earlier take.

If a working key was already shared

Editing the video doesn't revoke the key. Follow the credential provider's response steps. For example, AWS recommends replacing access keys that may be compromised and deleting the previous keys:
https://docs.aws.amazon.com/IAM/latest/UserGuide/securing_access-keys.html

Before uploading

The account uses fictional data wherever possible.
Every real credential in the prepared view is covered or removed.
Menus, transitions and other applications have been checked.
The file being uploaded is the export you reviewed.

Disclosure: AI assisted with drafting this article.

DEV Community: Vladimir Grigoryan