DEV Community: Nuco Z

Most online video text removers stop at 20 seconds — what to check before paying

Nuco Z — Thu, 29 Oct 2026 09:17:31 +0000

If you have tried to clean burned-in subtitles from a saved video, you have probably hit the same wall: the free online tool says it works, then you upload a 45-second ad and it either refuses the file or truncates it at 20 seconds.

That number is not random. Short caps keep free tools cheap to run. For a personal clip it is fine. For a 30–90 second ad, a product demo, or an actor reel, it is the difference between usable and useless.

What actually matters

1. Does it process only the segment you choose?
Most tools process the whole upload. If you only need the lower third cleaned, you should not pay for the opening and closing shots. A segment picker (5–90 seconds) is more useful than a vague "up to 10 minutes" claim.

2. Is the output a rebuilt frame or a cover-up?
Blur and crop are valid routes when the frame can lose pixels. They are not the same as rebuilding the background. Ask what happens behind the letters.

3. What is the hard case?
Faces, hands, fast motion and heavy compression. Any tool can look clean on a static wall. Test the busiest five seconds first.

4. Does it keep audio and frame size?
A clean frame that changes the aspect ratio or drops the audio is not a finished job.

The limits I would publish

At CleanVideoText (the tool I work on), we clean one selected segment of 5–90 seconds per job, keep the original audio and frame size, and charge only for that segment. Uploads can be up to 200 MB / 10 minutes, but each job is the segment you pick. We do not claim a clean result on every background, and we do not support removing a third-party watermark for redistribution.

That last part matters: removing text from footage you own or are licensed to edit is a different job from stripping someone else's watermark. The second one is not a feature, it is a rights problem.

A short checklist

What is the maximum length per job, and is it enforced before payment?
Can you choose the exact segment?
Is the output the full frame or a cropped one?
Does it keep audio and aspect ratio?
Can you test the hardest five seconds first?

If a tool cannot answer those five questions, the 20-second limit is not the only thing you will discover after paying.

Try the sample: https://cleanvideotext.com/

Fixing text in an AI-generated image is an inpainting problem, not a prompt problem

Nuco Z — Mon, 26 Oct 2026 15:11:56 +0000

TL;DR: If the picture is right and one word is wrong, do not regenerate. Remove the glyphs, inpaint the surface behind them, then re-render the replacement. That is a local editing problem, not a prompt problem.

AI image generators are good at moons, gardens and lighting. They are still unreliable at spelling. A poster comes back with “MOONLIGT” instead of “MOONLIGHT”, a menu swaps a letter, or a book cover has a word that looks almost right until you read it.

The instinct is to reroll the prompt or the seed. That is the wrong default when the composition and style already work. A new generation changes the moon, the plants, the light and the layout, and it can introduce a different spelling error. You spend another round of credits and review time to fix one word.

Why this is not an OCR problem

OCR reads the lettering. It does not remove it, and it does not draw a replacement. A text layer from OCR would sit on top of the old pixels, not replace them.

The operation has three parts:

Locate and remove the old glyphs.
Rebuild the surface behind them (inpainting).
Re-render the new string with matching weight, spacing, colour and alignment.

Missing any one of them gives a visible failure: a ghost of the old word, a clean patch with no text, or a new word that clearly belongs to another typeface.

A practical workflow

Upload the image. JPG, PNG and WebP up to 10 MB.
Enter the current string exactly as it appears, including the misspelling. You can also select the text region in the preview.
Enter the replacement.
Generate, inspect at 100%, then download.

The example below is a generated poster. The headline was misspelled. Only the headline changed; the moon, garden, lights and layout are the same pixels.

What I check before accepting the result

Letter edges at 100%. Zoom in; soft edges and duplicated strokes show up here.
Background continuity. Grain, gradients and shadows should not restart at the edge of the replaced word.
Baseline and spacing. The new word should sit on the same line and keep the same tracking.
Colour and shadow. A flat fill over a lit surface is the usual giveaway.
The rest of the image. Compare the untouched area against the original.

Limits

The exact typeface is not recoverable from a flattened image. Weight, spacing and colour can be matched; the font file cannot.
Rebuilt backgrounds are approximations, especially over faces, logos and detailed objects.
Curved, decorative or very small text may need a second attempt.
Dense non-Latin scripts vary more than Latin text; check at full size.
This is one image at a time. It does not open PSD, AI or layered files, and it is not a batch pipeline.

When to reroll instead

Regenerate if the composition is wrong, if the image has many errors, or if you want a different style. Editing the words only makes sense when the picture is right.

Try it

The workflow above is the AI image text editor. The first edit is free; a Google sign-in protects the credit, and no payment method is needed. For ordinary screenshots, the same image text editor works the same way. If the problem is a plain typo, the fix a typo in an image page is a narrower entry point.

I work on Reword Image, the tool used in the example. The before/after image is a real product example, not a mockup.

How to fix one wrong word in an image without rebuilding the design

Nuco Z — Sat, 24 Oct 2026 15:53:34 +0000

A single outdated word is enough to make a screenshot, a price tag or a poster look wrong — and rebuilding the whole design to fix it is the long way around.

I keep a browser tool for exactly this: edit text in image. No design file, no font hunting, no layer stack.

The actual flow

Upload a JPG, PNG or WebP.
Type the current wording exactly as it appears in the picture.
Type the wording you want instead.
Generate, review the preview, then download.

The editor replaces the text and keeps the rest of the picture. On a flat surface like a browser field the surrounding pixels barely move; on a textured surface like a menu board they shift a little, which is expected.

Where this is worth doing

Screenshots with a stale label or an old date.
Posters and price tags where only a price changed.
Product photos with a wrong model name.

Limits worth knowing

Small, curved, repeated or heavily textured lettering can need another try. The download is a flattened image, so keep the original file.

How to Edit Text in an Image Without Photoshop

Nuco Z — Mon, 19 Oct 2026 01:56:10 +0000

Most people hit the same wall: there is text baked into a picture and it needs to change. A typo on a product photo. An old price on a flyer. A date that no longer applies on a screenshot. The usual answer is "open it in Photoshop" — but that assumes you have Photoshop, the original design file, and the font that was used.

That is why I built Reword Image. It is a browser tool that changes the words already inside an image, no design file required.

What it does

Upload a JPG, PNG or WebP, type the text you currently see in the image and what it should say instead, and the tool generates a new version with your wording. The original font, color, size and background stay intact — it replaces the words, not the whole picture.

Common jobs it handles:

Fixing typos on product photos
Updating prices or dates on marketing material
Changing text on screenshots and mockups
Translating text that is baked into an image
Refreshing old creative without a designer

Why not Photoshop

Photoshop is the right tool for a lot of things. But for "change these five words in this one picture," it is overkill — you need the original layered file, the right font installed, and an hour of your day. Most people do not have any of those three things when the request comes in.

A dedicated tool keeps it simple: upload, type, download. The first edit is free, with one-time credit packs after that. It runs in any modern browser, in English and Spanish.

When a full editor is still the answer

If you are rebuilding a layout, compositing multiple images, or designing from scratch, use a proper editor. But when the image is done and only the words are wrong, there is now a faster path — and it does not involve font hunting.

Try it at rewordimage.com.

How I Edit Text That Is Already Baked Into an Image

Nuco Z — Sun, 04 Oct 2026 15:58:55 +0000

There's a specific image problem that most tools have no good answer for: the words are already part of the picture, and the original design file is gone.

A cafe renames itself, but the sign photo is already printed on the menu. An event moves a week later, but the poster only exists as a JPG. A price goes up and the shelf label is a flat photo from two years ago. In each case, re-shooting costs more than the change is worth.

Photoshop is the obvious answer and usually the wrong one. There is no text layer to click into — the letters stopped being text the moment the file was flattened. You aren't editing text, you're editing a picture of text.

That's the problem I built Reword Image around.

Why "just put a new text box on top" doesn't work

The obvious workaround is to cover the old words with a rectangle and type new ones over the top. It demos fine and falls apart immediately:

The background is never flat. A painted sign has brush texture, a chalkboard has dust, a label has paper grain. A solid rectangle reads as a patch from across the room.
The lighting is baked in. Real photos have a gradient across the surface, a shadow from the frame, a falloff toward the edge. A flat fill ignores all of it.
The lettering has depth. Engraved, embossed or weathered type casts its own small shadows. New flat text sits on the image instead of in it.

So the text has to be replaced in place: the region gets rebuilt with the material, lighting and perspective it sits on.

What that looks like

A wooden hanging sign, renamed. The grain, the chain shadow and the slight perspective of the photo all have to survive:

An event poster with the date moved:

And the harder case — removing lettering entirely and rebuilding whatever was behind it:

What works, and what doesn't

Input quality dominates the result, so it's worth being specific instead of listing features.

Works well

Large, clear lettering
Simple to mid-complexity backgrounds
Short replacements — a word, a name, a date, a price
Straight-on or mildly angled shots

Needs another attempt

Very small text (roughly under 20px in the source image)
Curved, script or heavily decorative lettering
Long replacements — the new text has to fit the space the old text occupied
Lettering on a busy, high-frequency background

Not what this is

Not a design tool. It won't hand back a PSD or recover the original font file.
Not a general object-removal inpainter — there's a narrower eraser for lettering.
Not a one-click fix for everything. Some images take two or three attempts.

I'd rather state that up front than let people find out after paying.

The workflow

Deliberately narrow, because a wider one would be a worse one:

Upload a JPG, PNG or WebP
Type the text that's currently in the image
Type the replacement
Generate, compare against the original, download

Step 2 surprises people. You can't drop a freely positioned new text layer, because the whole point is replacing what is already there. The trade-off pays off: the result keeps the original typography, perspective and material instead of looking pasted on.

Around that core there are three focused tools and one eraser:

Replace text in an image — the general case
Change a date in an image — dates, deadlines, schedules
Edit numbers and prices — prices, quantities, opening hours
Remove text from an image — erase lettering and rebuild the background behind it

One credit covers one complete edit, not one text box: changing a date, a price and a headline in the same image is a single credit.

Pricing, and two deliberate choices

The first edit is free at 1K output — sign in with Google to claim it, no payment method needed. After that it's one-time credit packs: $4.99 for 20 edits, $19.90 for 100, $49.90 for 300, each returning 2K output. No subscription.

Two things I decided early:

Credits don't expire. A subscription for a tool you use twice a quarter is a bad deal.
A technically failed edit returns the credit automatically. If the pipeline errors, that isn't the user's problem to pay for. Plenty of pay-per-image tools keep the credit; I didn't want to run one of those.

Try it

rewordimage.com — English and Spanish.

If you have a flattened image with the wrong words in it, that's exactly the case it's built for. And if it fails on your image, I'd genuinely like to see what the input looked like — the failure cases are the ones I need most.

How I Remove People From Photos Without Ruining the Background

Nuco Z — Thu, 27 Aug 2026 08:44:36 +0000

Have you ever taken a photo that was almost perfect, only to notice someone you didn't want in the background?

A stranger walking through the shot.

Someone standing behind you.

A person appearing in the corner at exactly the wrong moment.

The frustrating part is that the photo itself is usually fine. You just want to remove one thing.

But removing a person is only half of the problem.

The harder part is making the background look natural afterward.

I’ve been working on a simple way to handle this using AI, and along the way I found a few things that make a surprisingly big difference.

Start with the original photo

The first thing I recommend is using the highest-quality version of the original image you have.

It might sound obvious, but the surrounding image gives an AI removal tool important information about what should replace the person.

A person standing in front of a plain wall is relatively straightforward.

A person standing in front of a complicated background is a completely different problem.

Before editing, I usually keep the original image untouched and work on a separate copy.

Select the entire person

One of the easiest mistakes is selecting only the obvious part of the person.

If you want to remove someone, try to include their entire body.

That means their head, hair, body, hands, legs, shoes, bags, and loose clothing.

Otherwise, you may end up with something strange like a hand or shoe remaining in the final image.

At the same time, don't make the selection unnecessarily huge.

If there is another person standing nearby, selecting too much can affect parts of the image you actually wanted to keep.

Give the selection enough room, but stay aware of what's around it.

Don't forget the shadow

This is probably the detail people notice only after they have already removed the person.

Imagine removing someone from a beach photo.

The person disappears.

But their shadow is still sitting on the sand.

Something immediately feels wrong.

The same thing can happen with shadows on roads, floors, walls, or other surfaces.

So before removing someone, look around their feet and underneath their body.

Ask yourself:

What else in this photo exists because this person is here?

Sometimes removing the shadow or reflection makes as much difference as removing the person itself.

Be careful when people are close together

Removing one person from a crowded photo is much harder than removing someone standing alone.

If two people are next to each other, a large brush can easily include part of the person you want to keep.

The same problem can happen around faces, hands, bags, signs, railings, windows, and other objects.

For these situations, I prefer using a more controlled selection.

The goal isn't to make the biggest possible selection.

The goal is to tell the AI exactly what needs to change.

Look at the background, not just the person

After the removal is finished, don't immediately decide that the result is good just because the person is gone.

Look at the background.

Does the ground still look natural?

Did a straight line suddenly move?

Is a texture repeated?

Did something near the person change unexpectedly?

Does the surrounding area still make sense?

I like to check the image at two different levels.

First, look at the entire photo normally.

Then zoom into the edited area.

The first view tells you whether the image feels natural.

The second helps you find small problems.

Some backgrounds are much easier than others

AI image removal works particularly well when there is useful information surrounding the object being removed.

Simple backgrounds such as sky, walls, roads, sand, grass, and floors can be easier to reconstruct.

Complicated backgrounds are more difficult.

For example, imagine someone standing directly in front of a sign.

The entire middle section of the sign is hidden by the person.

There may be no visible information showing what was actually behind them.

An AI model can create a plausible continuation, but it cannot know with certainty what was originally there.

This is an important thing to understand about AI image editing.

The goal is often to create something that looks natural, not to recover pixels that no longer exist.

What I use for quick edits

For a simple removal, I don't really want to open a full image editor and spend several minutes setting everything up.

Usually I just want to upload an image, mark the unwanted area, and see the result.

That's why I built ImgEraser.

It focuses on one simple workflow: upload an image, brush over the person or object you want to remove, and let AI reconstruct the selected area.

You can try it here:

https://imgeraser.com/

The interesting part isn't just the AI model.

The editing workflow matters too.

If the selection is wrong, even a good model can produce a bad result.

If the selection is accurate and there is enough surrounding information, the result can be much more convincing.

What if the first result isn't good?

Don't keep editing the already-edited image.

Go back to the original.

Then change the selection.

If part of the person is still visible, make the selection slightly larger.

If something nearby was accidentally changed, make it smaller.

For complicated images, you can also think about different parts of the image separately instead of trying to solve everything with one enormous selection.

And always keep the original

I know this sounds obvious, but don't overwrite your original photo.

Keep the original and save the edited version separately.

That way you can compare the two versions or try another approach if the first result isn't what you wanted.

The best AI edit is the one nobody notices

This is probably the part of AI image editing that I find most interesting.

The best result isn't necessarily the one that looks the most "AI generated."

Actually, it should be the opposite.

If someone looks at the finished photo and doesn't notice that anything was changed, the edit has done its job.

That's the idea behind ImgEraser.

Not trying to replace a professional image editor.

Not trying to add hundreds of editing controls.

Just making one annoying photo-editing task a little easier.

If you have a photo with an unwanted person or object in it, try it with your own image:

https://imgeraser.com/

I'm especially interested in the difficult cases.

Crowded backgrounds, reflections, detailed patterns, overlapping people, text, and anything else that produces an unexpected result.

Those cases are much more useful than a perfect example because they show where the experience still needs improvement.

Your AI Summary Is Not Evidence: Building a Timestamped YouTube Research Workflow

Nuco Z — Mon, 10 Aug 2026 11:41:20 +0000

A two-hour interview can be easy to summarize and surprisingly hard to cite.

That gap matters more than it first appears. A fluent AI summary may tell you what a video was about, but it does not automatically tell you where a claim came from, which words were actually spoken, or whether a number was copied correctly. For research, study notes, subtitle work, and content repurposing, the useful artifact is not just a summary. It is a summary with a path back to the source.

This is the workflow for turning YouTube captions into evidence that can be searched, checked, and exported.

Summary and evidence are different artifacts

A summary is an interpretation. A transcript is a record of the words available in a source. They solve different problems.

When a model summarizes a long video, it may compress several statements into one sentence, omit a qualification, or merge two speakers. That can be fine for discovery. It is risky when the result becomes a quote, a statistic, a product requirement, or a paragraph that someone else needs to audit.

The safest sequence is:

Search the transcript to find the relevant passage.
Read the surrounding caption segments.
Jump to the original timestamp.
Use the verified passage as the evidence for your summary.

Search in text, decide with context, verify in video.

That extra loop is small. It is also the difference between the model saying something and the source supporting it.

Start with the caption track

YouTube videos do not all expose the same transcript data. A public video may have creator-uploaded captions, automatically generated captions, multiple language tracks, or no accessible caption track at all.

A reliable workflow needs to preserve that distinction. Manual captions and automatic captions should not be presented as identical sources. Automatic captions are useful, but names, numbers, accents, and technical terms deserve a timestamp check.

There is another important boundary. Retrieving an existing caption track is not the same as downloading the video or audio and running a new speech-to-text job. If the captions already exist, moving the text is usually faster, lighter, and easier to audit.

YT to Text is designed around that boundary. Paste a public YouTube URL, and it opens the caption track that YouTube makes available. There is no video or audio upload step.

Videos can still be unavailable. Private, removed, restricted, still-live, or caption-free sources may not provide a usable transcript. Repeating the request cannot manufacture a missing track, so the honest result is an unavailable source.

Search exact phrases before broad topics

Long transcripts become practical when they behave like searchable documents.

Start with the most specific term you know, such as a surname, product name, uncommon technical phrase, or short quote. If it does not appear, shorten the query one word at a time. A narrow search gives you a smaller set of passages to verify.

When a match appears, do not copy only the matching line. Read at least one segment before and after it. Captions are split for timing, not for meaning. The sentence you need may continue in the next cue, and the speaker's qualification may be in the previous one.

This is also where transcript search beats scrubbing. A video player is a linear interface. Research is not. Searching the text lets you move directly to the relevant moment, then use the video for the final judgment.

Keep the timestamp attached

A transcript without timing is convenient until you need to check it.

Keep the original timestamp beside important passages. This lets you answer practical questions quickly:

Did the speaker say 15 or 50?
Was the claim about the product, the market, or a hypothetical?
Did the sentence belong to the host or the guest?
Was the word an industry term or an automatic-caption error?

Timestamp verification is not only for journalists. It helps students cite lectures, editors prepare subtitles, researchers collect quotes, and content teams turn interviews into accurate briefs.

For a short note, a clean reading view is comfortable. For a claim that will be published, the timestamp is part of the evidence.

Pick an export format that matches the next task

TXT, SRT, and VTT are different working formats, not decorative file extensions.

TXT is the simplest option for reading, notes, search, and AI prompts. Use it when the words matter more than timing.

SRT is built for subtitle cues with sequence numbers and start/end times. It is a natural handoff to video editors and subtitle tools.

VTT is designed for web video and the HTML track element. Use it when captions will be attached to a browser-based player.

If you are preparing a transcript for an AI assistant, start with clean TXT for the main context and preserve a timestamped copy for verification. One source should be enough to produce all three exports. Re-submitting the same video just to change the format is unnecessary.

Give AI an evidence layer

A language model is useful after the source has been made searchable, not instead of that step.

For a long interview, split the transcript into logical sections. Keep timestamps on claims that may need checking. Ask the model to separate direct evidence from interpretation and to cite the relevant timestamp when it makes a factual statement.

A practical prompt can be simple:

Summarize this section in five bullets. For every factual claim, include the source timestamp. Mark anything that is an interpretation or an uncertain automatic caption.

The prompt is not a guarantee of accuracy. It is a reminder that the transcript remains the evidence layer and the model remains the analysis layer.

There is a more detailed version of this workflow in this guide for preparing a YouTube transcript for Claude.

Privacy belongs in the workflow

Transcripts can contain client names, unpublished research, or quotes that are not ready to share. A useful tool should make the working state private by default.

YT to Text keeps transcript workspaces private and removes anonymous job history after 24 hours. You can start without an account and complete up to three successful transcript requests per day. Failed requests do not consume the successful allowance.

Those product limits are intentionally visible. A trustworthy workflow should tell you when it can retrieve captions, when it cannot, and what happens to the working data.

You still need to respect copyright, platform rules, and the purpose of the original source. A transcript makes a video easier to analyze. It does not transfer ownership of the speaker's words.

The reusable loop

The complete process is short:

Copy the public YouTube URL.
Check that an accessible caption track exists.
Note the language and whether the captions are manual or automatic.
Search for an exact phrase.
Read the surrounding context.
Verify important lines at the original timestamp.
Export TXT, SRT, or VTT for the next task.
Keep the source URL with your notes.

The first-principles idea is to move the smallest useful representation of the source. If captions already exist, do not download a full video just to recover its words. Retrieve the text, preserve the timing relationship, and return to the source when accuracy matters.

That is how a transcript stops being a wall of text and becomes a dependable research surface.

Why a YouTube transcript tool should preserve the path back to the source

Nuco Z — Sun, 09 Aug 2026 14:15:53 +0000

There is a deceptively simple version of a YouTube transcript tool.

Accept a URL. Fetch some caption text. Put the result in a large text box. Add a copy button. Done.

That version works until someone tries to use the transcript for real work.

A researcher finds a number but cannot tell where it appeared in the video. An editor receives plain text but needs timed cues. A student searches a long lecture and sees one match without the explanation around it. An automatic caption misspells a name, yet the interface gives no clue that the line should be checked.

The difficult part is not turning captions into characters. It is preserving enough structure that those characters remain useful and trustworthy.

That became the main product constraint behind YT to Text, a private workspace for captions already available on public YouTube videos.

This article explains the decisions behind that constraint and the broader engineering lesson they reveal.

Begin with the user’s next action

It is tempting to define a transcript product by its input and output.

The input is a YouTube URL. The output is text.

But users do not arrive because they enjoy transforming URLs into strings. They arrive because another task is blocked.

They need to find a phrase in a lecture, verify a quote from an interview, copy a clean passage into notes, or import captions into an editing workflow.

Once the next action becomes the unit of design, the product requirements change.

Finding a phrase requires search and match navigation. Verifying a quote requires timestamps linked back to the source. Reading requires a clean text view. Editing requires a timed interchange format. Repeated work requires the successful result to remain available without fetching the source again.

The central object is therefore not a text blob. It is an ordered collection of caption segments.

Conceptually, each segment needs at least two pieces of information.

type TranscriptSegment = {
  startSeconds: number;
  text: string;
};

Everything else can be derived from that representation.

A readable transcript groups segments for scanning. A plain-text export joins the text. A timestamped view formats startSeconds. Search maps matches back to their segment. SRT and VTT derive timed cues from the same ordered source.

One retrieval. Multiple useful representations.

Search should preserve context

A naive transcript search can return a count and highlight a matching substring. That is technically correct but often practically weak.

Imagine searching a two-hour interview for a product name. The useful answer is not merely that the name appears four times. You need to move through those four moments, read the sentences around each match, and inspect the matching moment in the original video.

This leads to three small but important rules.

Search the source transcript without rewriting it. Keep an ordered list of match positions. Make every result reversible through its timestamp.

The first rule prevents search from changing the evidence. The second makes next and previous navigation deterministic. The third keeps the transcript connected to the video.

That final connection is easy to underestimate. A timestamp is not decorative metadata. It is a compact provenance link.

When automatic captions turn a technical term into a plausible but incorrect word, the user needs a cheap way to check. A clickable timestamp makes verification one action. Removing timestamps makes verification a second research project.

TXT, SRT, and VTT are different jobs

Export menus often present file formats as a cosmetic preference. In transcript workflows, each format represents a different job.

TXT is for reading, notes, search, and copy. It may be plain or include human-readable timestamps.

SRT is for editing and subtitle upload. It requires sequential cue numbers and time ranges in this form.

1
00:00:02,000 --> 00:00:06,000
The first caption line.

VTT is for web video and browser-oriented caption workflows. It begins with a WEBVTT header and uses a period for milliseconds.

WEBVTT

00:00:02.000 --> 00:00:06.000
The first caption line.

The formatting details look tiny, but tiny protocol differences are where supposedly convenient tools create expensive cleanup work.

There is another edge case. Caption sources often provide the start of a segment without a clean, editor-friendly end time. A formatter still needs to create a valid cue range. The implementation should derive the end from the next segment when possible and enforce a readable minimum duration when consecutive start times collapse together.

That behavior deserves direct tests. Formatting code is deterministic, easy to isolate, and likely to break downstream tools if it changes silently.

The KISS version is not to build three export pipelines. It is to keep one validated segment model and three small pure formatters.

Validation belongs at the boundary

Media metadata from an upstream service should be treated as untrusted input, even when the service is yours.

A successful-looking response can still contain an empty segment array, negative timestamps, missing language metadata, or a malformed job identifier. Allowing that state into the rest of the application spreads defensive checks across every component.

The simpler approach is to validate once at the boundary and fail with useful context.

The validated transcript job can then become the public interface used by search, rendering, download formatting, retention, and any private AI features. Those consumers should not reach into the extractor’s internal response shape.

This keeps the modules loosely coupled. It also makes failures easier to understand.

If retrieval failed, report a retrieval problem. If the video has no available captions, report that boundary. Do not return an empty transcript and hope the UI invents the correct explanation.

An empty successful result is not graceful degradation. It is an ambiguous error.

Do not claim capabilities the source cannot provide

One of the most important product decisions is also one of the least technical.

The free transcript workflow in YT to Text retrieves caption tracks already available for public YouTube videos. It does not generate a new transcription for a caption-free video. It does not present a machine translation as an original caption language. It does not make automatic captions more accurate by displaying them in a polished interface.

Those limits need to appear in the product, not just in an internal architecture diagram.

Private, removed, restricted, still-live, and caption-free videos may not produce a transcript. Available languages depend on the caption tracks YouTube provides. Automatic captions can contain errors in names, numbers, punctuation, accents, and technical vocabulary.

The interface labels the selected caption source and encourages timestamp verification for important lines.

This is a general design rule for tools built on upstream data.

Expose the boundary where users make decisions.

If the source is probabilistic or imperfect, hiding that fact does not remove uncertainty. It transfers the uncertainty to the user at the worst possible moment.

Privacy follows data minimization

A public YouTube link is public. A person’s collection of researched videos is not necessarily public.

The caption retrieval task does not require uploading the video or audio. It needs the public video identifier and the available caption source. Collecting the media file would create more transfer, storage, and privacy risk without helping the current task.

So the product does not request a video upload.

The generated workspace is private and is not exposed as a public SEO page. Anonymous history is removed after 24 hours. Private workspace and profile routes should remain outside search indexing.

This choice is useful beyond privacy. It also keeps the public site’s information architecture honest. Public pages explain the product and its formats. Private pages contain user work. Mixing the two can leak user activity while filling search indexes with thin, duplicated transcript pages.

Data minimization is often presented as a compliance exercise. Here it is also the simplest architecture.

Count delivered value, not attempts

YT to Text currently allows three successful transcript jobs before sign-in, and a free account receives five successful jobs per day.

The important word is successful.

An invalid URL, an unavailable video, missing captions, or a service failure does not deliver the thing the user came for. Counting that attempt against the allowance would be easy to implement and hard to justify.

Usage therefore needs to be reserved and recorded around a successful outcome, with idempotency protecting retries from being counted twice.

This is another case where the product principle shapes the data model. If billing or quota state is attached to button clicks, network retries and partial failures become user-facing unfairness. If it is attached to a durable successful job, the rules become much easier to explain.

The third successful transcript also remains usable. A quota boundary should prevent a new job, not retroactively damage the result that crossed the line.

Make transformations traceable

Transcript tools sit inside a larger family of products that compress or transform source material. Summarizers, document parsers, search indexes, analytics dashboards, and AI assistants all do some version of this.

The shared danger is losing the route back.

A summary without citations is quick but difficult to audit. A chart without access to underlying values is persuasive but fragile. A transcript without timestamps is readable but detached from the thing it represents.

The resulting design principle is simple.

Every useful transformation should preserve a cheap path back to its source.

In YT to Text, that path is a timestamp. In another product it may be a document page, a database row, a request identifier, or a source URL. The mechanism changes. The trust model does not.

Compression gives users speed. Traceability gives them agency.

A practical test

If you are building a transcript or media tool, take one real user task and follow it past the first successful response.

Do not stop when text appears on the screen.

Can the user find one exact phrase in a long result? Can they see enough surrounding context to interpret it? Can they reopen the corresponding source moment? Can they export a format their next tool understands? Can they tell when the upstream caption may be incomplete or inaccurate? Does a failed request consume their quota? Is private work accidentally becoming public content?

Those questions reveal more product quality than the size of the text box.

You can try the current workflow at YT to Text. Paste a public YouTube video with available captions, search for something specific, open a matching timestamp, and export the transcript in the format your next task needs. The first three successful transcripts do not require sign-in.

The output is text.

The product is the path that keeps the text useful.

Building a Privacy-First Face Analyzer That Runs in the Browser

Nuco Z — Fri, 31 Jul 2026 07:42:54 +0000

Most AI face analysis products begin with a simple architecture: upload a photo, send it to an API, run a model on a server, and return a score.

That approach is convenient, but it creates a data problem. A face photo is personal data, and many people do not want to upload it just to learn about visible proportions or face shape. When I built LookBlueprint, I started with a different constraint:

The useful first result should be possible without sending the original photo to a server.

This constraint shaped almost every technical decision in the product.

Running the first analysis locally

The free analysis runs in the browser using MediaPipe Face Landmarker and a bundled WebAssembly runtime. The model and runtime are shipped with the application, and the analysis work runs in a Web Worker so the interface remains responsive while landmarks are being detected.

The flow is roughly:

The user selects one clear, front-facing photo.
The browser validates and prepares the image for analysis.
The worker detects facial landmarks and basic image-quality signals.
Pure TypeScript analysis functions convert those landmarks into a versioned face-analysis snapshot.
The UI renders the snapshot into focused results and educational explanations.

The original image is not uploaded for the free result. There is no login requirement for that workflow, and the result is kept temporarily in the browser session.

This is a practical privacy improvement, but it also changes the engineering trade-offs. The model must load reliably on a range of devices, image processing must fit within browser memory limits, and errors must be understandable to a person who is not debugging a machine-learning pipeline.

Measuring structure instead of pretending to measure beauty

A face-analysis score can sound more objective than it really is. I wanted the product to expose measurable references without presenting them as a universal ranking of people.

LookBlueprint separates several types of output:

Visible left-to-right symmetry and pair differences.
Face-shape candidates with confidence percentages.
Vertical thirds and horizontal fifths.
Face length-to-width and facial width-to-height ratios.
Eye-shape references and canthal tilt.
Jawline and lower-face structure.
A separate photo-reliability signal.

The overall rating is not treated as a scientific truth. It combines selected structural signals, while camera reliability remains separate. Natural asymmetry, lighting, head rotation, expression, lens distortion, and landmark quality all affect what can be measured in one photo.

That distinction matters. A result should help someone understand the image in front of them, not tell them what they are worth or reduce a complex person to a number.

The hardest part is measurement quality

Face landmarks are not the same thing as ground truth. A small change in camera angle can change the apparent proportions. Hair can hide the jawline. Low light can reduce landmark stability. A wide-angle selfie can exaggerate the center of the face.

Because of that, the interface explains limitations next to the result instead of hiding them in a legal page. It reports confidence, identifies the photo conditions that affect interpretation, and encourages users to treat the output as a reference from that image.

This also makes the error states important. If a photo does not contain a usable face, the user needs a clear next step: try a brighter, more front-facing image with the face unobstructed. A generic "analysis failed" message is technically accurate but not useful.

A small architecture with explicit boundaries

The application uses a Next.js frontend, a Web Worker for the browser analysis pipeline, and pure analysis modules that transform landmarks into a typed, versioned FaceAnalysisSnapshot.

That snapshot is the boundary between detection and presentation. The worker does not need to know how a result card is rendered, and the UI does not need to know how the model locates landmarks. This keeps the core calculations testable and makes it possible to add focused tools without duplicating the detection pipeline.

The product currently includes focused views for rating, symmetry, face shape, proportions, canthal tilt, jawline, eye shape, and a neutral structure view. It also includes guides covering methodology, research references, accuracy, bias, limitations, privacy, and practical style questions.

What happens when a user wants a report?

The free analysis stays in the browser. For the optional personalized Face Blueprint report, the browser prepares a constrained analysis copy for the report workflow rather than sending the original source file. The copy is limited in size and dimensions, and the report can be delivered as an on-page result, a multi-page PDF, and a keepsake image.

The important product decision is to make that boundary visible. Users should know which workflow is local, which workflow is optional, and what kind of image copy is involved.

Why build it this way?

The first-principles answer is simple: if the product only needs facial landmarks and ratios for its free result, uploading the original photo is not a necessary starting assumption.

Local processing does not solve every privacy or accuracy problem. It does, however, reduce unnecessary transmission, give users a clearer mental model, and force the product to be honest about what one photo can and cannot tell us.

You can try the free browser-based analyzer at lookblueprint.com. The goal is not to produce a definitive judgment. It is to give people a private, understandable way to explore the visible patterns in a photograph.

Building a Low-Cost AI Brainrot Video Pipeline on Cloudflare

Nuco Z — Sat, 18 Jul 2026 10:13:19 +0000

Short-form video tools often look like a single button, but the product experience is really a small distributed system. A useful pipeline has to accept messy inputs, turn them into a script, generate media, report progress clearly, and keep the cost of each render predictable.

I am building BrainrotKit around that problem. The goal is not to hide the workflow behind a magic button. The goal is to make each stage understandable enough that a creator can review the result and decide whether it is worth generating the next stage.

1. Start in the browser when the browser is good enough

PDF parsing and OCR do not always need a paid server. A browser can extract text from many PDFs locally, and an OCR library can handle image-based notes without sending the original file to a backend. This reduces latency, lowers storage requirements, and gives users a simpler privacy story.

The important boundary is quality. If the browser cannot confidently extract the content, the UI should say so and ask for a clearer file. Quietly passing a bad OCR result to a language model only creates a more expensive bad result.

2. Separate planning from media generation

The text model should produce a compact, structured plan before an image or video model is called. A useful intermediate object contains:

a one-sentence hook;
the narration script;
a visual description for each beat;
the target duration;
a short caption and title.

This separation makes retries cheaper. If the image looks wrong, regenerate the image prompt instead of paying to rewrite the entire script. It also makes the system easier to debug because every output has a visible input.

3. Use a job state machine, not a spinner

Media generation is asynchronous. A request can move through "queued", "planning", "generating-image", "generating-voice", "generating-video", "ready", or "failed". The frontend should display the current stage, an estimated next action, and a useful error when something goes wrong.

A generic spinner is not enough for a ten-second wait. Users should know whether the system is still planning, waiting for a provider, or retrying a failed asset. This is also where idempotency matters: refreshing the page must not create a second paid job accidentally.

4. Track credits at the product layer

Provider prices change, so the product should not expose raw API costs as if they were permanent. I prefer a simple credit ledger: each operation reserves credits, the worker records the actual result, and unused reservations are released when a job fails before generation.

Short drafts are useful here. A five-second render is a cheaper way to validate a prompt than a fifteen-second render, and the UI can make that tradeoff explicit before the user starts.

5. Keep the user in the review loop

An AI video is not finished just because the provider returned a file. The creator still needs to check pronunciation, pacing, captions, and whether the visual actually supports the idea. The product should make preview, download, retry, and delete actions obvious.

That is the thinking behind BrainrotKit: a focused AI brainrot video workflow for turning text, notes, and PDFs into short-form concepts while keeping the intermediate steps visible. The meme layer can be playful; the engineering underneath should be boring, observable, and cost-aware.

A practical first release

For a small team, the first production version can stay intentionally narrow:

browser-side extraction for text and PDFs;
one text model for script planning;
one image provider and one video provider;
durable project and credit records;
clear loading states and failure messages;
a short export before longer generations.

This is enough to learn where users actually get stuck. The first principle is to measure the complete user journey, not just whether an individual model call succeeded. When the workflow is understandable, creators can make better decisions and the platform can improve without wasting their budget on invisible retries.

Building a Small Static Game Wiki with Next.js and Cloudflare Workers

Nuco Z — Wed, 01 Jul 2026 03:35:02 +0000

I recently put together a small static guide hub for CookieRun Classic: CRClassic.wiki. It is a simple content site, but the deployment path had a few details that are easy to miss when combining Next.js static export, Cloudflare Workers Static Assets, sitemap generation, and game-guide SEO.

This is a short technical note on what ended up mattering.

The site shape

The site is not an app dashboard. It is a focused information hub with separate pages for player intent:

codes and redeem steps
beginner route
cookie, pet, and treasure tier pages
PC setup
reroll and meta notes
a central wiki hub

That split helps because each URL answers a different question. A player searching for a redeem flow does not need to land on the same page as someone comparing Cookie upgrades.

Static export was the right fit

For this kind of site, static output keeps the deployment simple:

// next.config.mjs
const nextConfig = {
  output: 'export',
  images: {
    unoptimized: true,
  },
}

export default nextConfig

The Cloudflare Workers config points directly at the generated out folder:

{
  "name": "cpclassic",
  "compatibility_date": "2026-07-01",
  "assets": {
    "directory": "./out",
    "html_handling": "auto-trailing-slash",
    "not_found_handling": "404-page"
  }
}

The small metadata details mattered

The site needed normal page metadata, but also page-specific Open Graph images so each guide has a relevant preview instead of one generic logo.

A few details I made sure to include:

canonical URLs for every route
robots.txt and sitemap.xml
max-image-preview: large for Google image previews
page-specific og:image and Twitter card images
a real favicon instead of relying only on 32px PNG files

The public sitemap is here: https://crclassic.wiki/sitemap.xml

Content pages need more than lists

For game-guide pages, a plain tier table is rarely enough. The more useful structure is:

who should use this option
when to upgrade it
when to stop investing
what mistakes to avoid
what related page to read next

That is the approach I used on the Cookie Run Classic Tier List: the page includes rankings, but the real value is upgrade logic and account-stage guidance.

Takeaway

For a small wiki, the technical stack can stay boring. The hard part is making each page answer a real search intent and making sure crawlers can clearly see the URL, canonical, sitemap entry, image preview, and internal links.

If you are building a similar static guide hub, I would start with the content architecture first, then wire the metadata and deployment around that structure.

How I Built a Fan Guide Hub for BOMBANANA!

Nuco Z — Fri, 26 Jun 2026 07:23:19 +0000

I recently put together a fan guide hub for BOMBANANA!, a new co-op bomb defusal game where three players have to coordinate under different communication limits.

The site is here:

https://bombanana.online/

Why I built it

The game is funny and chaotic, but the learning curve is mostly about communication. New players do not only need a list of rules. They need a content structure that answers practical questions:

What does each role do?
Which player should speak first?
How should the team describe modules?
What should a beginner team practice in the first session?

That shaped the site architecture more than keyword research alone.

Content structure

I split the guide into a few core sections:

Role guides: https://bombanana.online/roles
Module guides: https://bombanana.online/modules
First-session guide: https://bombanana.online/beginners/how-to-play
Team callouts: https://bombanana.online/communication/team-callouts

The goal is to make the site useful during actual gameplay, not just readable as a long article.

What I learned

For a small game guide site, the best pages are not always generic “ultimate guide” pages. The highest-value pages are often specific resources that players can use immediately:

a checklist
a module walkthrough
role-specific advice
short callout systems
screenshots that match the game state

Next steps

I am continuing to improve the guide with more screenshots, better internal links, and clearer module pages as more players search for help around the demo and full release.

If you are building a small content site for a game, my main takeaway is simple: organize by the player’s next decision, not by what looks like a clean blog category.