DEV Community: dylan yu

Checking AI image metadata: 20 useful reads and listings

dylan yu — Wed, 21 Oct 2026 23:44:30 +0000

Before you post an AI-assisted image, it is worth knowing what the file says about itself. Generators and editors can leave a signed C2PA manifest (what LinkedIn's "CR" icon reads), XMP or IPTC tags marking the image as AI-generated, prompt text in PNG chunks, and ordinary EXIF such as GPS. None of it shows in the preview.

The pages below explain those layers, and each one points to Remove AI Meta as a way to inspect and strip them in the browser. If you want to go straight to the tool, the AI metadata cleaner handles one image at a time.

Understanding the labels

Why Instagram Adds an "AI info" Label to Your Photo: how a small generative edit can trigger the label.
The LinkedIn CR icon is a manifest, not a sticker: what the icon actually reflects.
Does a screenshot remove C2PA data from a ChatGPT image?: a plain answer, with its limits.
Clean a JPEG in the tab you already have open: why cleaning a file is not a promise about platform labels.

Hands-on how-tos

Strip C2PA and IPTC Metadata From AI Images Before You Publish
Inspecting and Removing C2PA and IPTC Metadata from Images
Stable Diffusion and ComfyUI PNGs carry your prompt: finding the saved generation recipe in a PNG.
What Your AI Images Quietly Say About Themselves: three layers to check, with an exiftool command.
What's actually inside your image (and PDF) before you upload it: covers PDFs as well as images.
Where AI metadata hides in a JPEG, PNG and WebP: a slide deck on locations and verification.

For developers

ai-image-metadata-checklist: a GitHub checklist of metadata locations with exiftool commands.
MCP registry entry: the tool as a Model Context Protocol server.
Troubleshooting Remove AI Meta: error messages and fixes.

Where it is listed

AI Tool Finder
WithAITools: the Instagram-focused page.
Product Watch
BuildVoyage: includes the tech stack.
Uneed
newname.ai
directree

A note on limits

Removing metadata changes what the file declares. It does not remove pixel watermarks such as SynthID, and platforms may still label content based on other signals or on your own disclosure. To check and clean a file, use the AI metadata cleaner on Remove AI Meta.

How to Test Hair Colors Before You Dye Your Hair

dylan yu — Tue, 20 Oct 2026 23:09:30 +0000

Dyeing your hair is a big commitment, and a color that looks great on a swatch can look very different on you. Here is a simple process for testing hair colors first.

1. Know your skin undertone

Blue or purple wrist veins suggest a cool undertone; green suggests warm. Cool tones suit ash and burgundy; warm tones suit copper and honey blonde.

2. Preview colors on your own photo

Take a clear, evenly lit selfie, then use an AI tool such as this AI hair color try-on to see different shades and styles on your own face in seconds.

3. Check the color in different light

Look at previews on a phone and a computer.

4. Do a strand test

Test the real dye on a hidden strand and check it when dry.

5. Plan the whole look

If you want to see outfits next to your new shade, an AI clothes changer can help you preview complementary clothing colors.

Test digitally first, strand test second, and dye with confidence.

Why Instagram Adds an "AI info" Label to Your Photo, and How to Check the File First

dylan yu — Tue, 20 Oct 2026 12:54:48 +0000

A photo with one small generative edit, like removing a stray sign with Photoshop's Generative Fill, can come out of the editor marked as AI media. Upload it to Instagram and you may get the "AI info" label, which is the same family as Meta's older "Made with AI" label. In many of these cases the signal is not in the pixels. It is in the metadata.

What triggers the label

Meta has said it reads industry-standard markers that tools write into the file. Three are worth knowing:

C2PA Content Credentials. A signed manifest describing how the image was made. In a JPEG it lives in JUMBF boxes inside APP11 segments. Adobe Firefly, Photoshop generative tools, and several image generators write it.
IPTC DigitalSourceType. A field whose values include trainedAlgorithmicMedia (fully generated) and compositeWithTrainedAlgorithmicMedia (a real photo with generated parts).
XMP history. Editors record tool names and edit steps in XMP. Generative Fill and Firefly leave a clear trail here.

Check the file before you change anything

ExifTool shows every tag group, including duplicates:

exiftool -G1 -a -s photo.jpg | grep -i -E 'c2pa|jumbf|DigitalSourceType|Credit'

No output means none of those markers are present. A JUMBF or C2PA group means a Content Credentials manifest is embedded. A DigitalSourceType line tells you how the file describes itself. Credit sometimes holds a generator name.

If you don't want to install anything, you can remove Instagram AI info in the browser instead. It reads and cleans the file on your device, so the image isn't uploaded anywhere.

Strip it

Write a new file and keep the original:

exiftool -all= -o clean.jpg photo.jpg

-all= deletes all metadata, and -o writes to a separate file. This is blunt. It removes copyright, camera and lens data, GPS, and the ICC color profile. Without the profile, colors can shift slightly in some viewers, and dropping the Orientation tag can make a portrait display sideways.

To keep color, copy the profile back from the source:

exiftool -all= -tagsfromfile @ -icc_profile -o clean.jpg photo.jpg

@ means the source file. Copy copyright or orientation back the same way if you need them.

If you only want the Content Credentials manifest gone and the rest left alone, a dedicated tool to remove C2PA does just that, also on-device.

Check again, then upload

exiftool -G1 -a -s clean.jpg | grep -i -E 'c2pa|jumbf|DigitalSourceType|Credit'

Empty output is the goal. Upload that exact file. Don't open it in another editor first, because many apps write their own XMP on save.

What stripping can't do

Metadata is only one signal. Some generators also embed an invisible watermark in the pixels (Google's SynthID is one example), and stripping EXIF, XMP, and C2PA leaves that in place. Meta also runs its own detection. So a file with an empty grep can still be labeled.

The label exists for disclosure. If an image is substantially AI-generated, keep the label or say so in the caption. Cleaning metadata makes most sense when the mark is a side effect of a small fix on a photo you took.

Troubleshooting

The label still appears. Run the check on the exact file you uploaded. If markers are still there, you uploaded the wrong copy. If the output is empty and the label stays, another signal was used, and stripping again won't change it.

Saving or exporting brings the data back. Phone galleries and many editing apps rewrite XMP on export, and Photoshop or Lightroom can write a new manifest if the edit history still includes a generative step. Strip as the last step, or re-check after every save.

Screenshots. A screenshot usually drops all metadata, but it also resamples the image and can catch UI around the edges. It won't remove a pixel watermark. Treat it as a last resort, not a fix.

Shipping Work Through a Desktop Agent: First Bot, Computer, Then Routines

dylan yu — Thu, 15 Oct 2026 10:59:58 +0000

"AI agent" posts usually skip the boring part: how a desktop agent actually holds a computer, asks for approval, and runs again tomorrow without you re-explaining the job. If you are evaluating Grok Bot-style setups, the useful mental model is three layers — identity, computer, routines — not a chat demo.

Layer 1: know what the product is (and is not)

Start with a plain definition page before you install anything. What is Grok Bot is the right altitude: an agent that can use a computer and tools on your behalf, with approvals, not a magic autopilot that silently spends money and posts as you.

Read that before comparison charts. Feature matrices are useless if you still think the product is "ChatGPT with a sidebar."

Layer 2: first bot as a scoped employee

Your first bot should have a job description, not a personality. Good first jobs are narrow:

Draft a weekly changelog from merged PRs
Triage inbound email into labels + draft replies you still send
Watch a folder and summarize new PDFs

A practical first bot path matters more than a tour of every plugin. Scope equals safety. Wide open "do whatever" agents are how people discover irreversible actions the hard way.

Layer 3: the computer is the real API

Chat is the interface. The computer is the capability. Files, browser, shell, and connected apps only matter if you understand what the agent can touch and what still needs your click.

Skim computer with the same seriousness you would give IAM docs. Ask:

Does this run on a remote box, my machine, or both?
Which actions are reversible vs. externally visible?
Where do approvals show up, and can a routine bypass them?

If those answers are fuzzy, do not wire production credentials yet.

Routines and skills turn demos into ops

One-shot prompts are toys. Recurring work needs schedules, skills, and failure modes. Skills and routines is where an agent stops being a chat novelty and starts looking like a junior operator: same brief, same tools, logged outcomes.

Ops hygiene that actually helps:

Name the routine after the outcome (weekly-changelog), not the model.
Keep secrets out of the prompt; use connected accounts and approvals.
Log failures with the step that died (auth, timeout, empty input).
Prefer read → draft → human send over silent send for anything external.

For team-shaped usage, ops notes on handoff and ownership prevent the classic failure: five people sharing one bot and nobody knowing who approved the outbound message.

Compare on jobs, not logos

When you stack Grok Bot against other agent products, compare job completion under approval constraints, not homepage adjectives. A grounded compare page plus concrete use cases beats another "10 AI agents in 2026" listicle.

Checklist before you commit a workflow:

Can I state the job in one sentence?
Does the agent have only the computer access that job needs?
Is every externally visible action behind an approval I understand?
Can the same job rerun next week as a routine without rewriting the brief?
Do I know how to recover when a step sticks or a login expires?

Desktop agents are less about clever prompts and more about boring operational design. Get the first bot narrow, the computer boundaries explicit, and the routine repeatable — then the chat UI finally earns its keep.

First-Session Design for Browser Mech Games: Controls, Upgrades, Boss Gates

dylan yu — Thu, 15 Oct 2026 10:58:36 +0000

Browser mech fighters look casual until the first boss. Then the session splits into people who learned the control model and people who spent the whole run buying the wrong upgrades. If you build or document these games, treat the first session as a product surface: controls literacy, upgrade priority, and a boss gate that teaches — not punishes.

I have been reverse-engineering what good first-session pages do for titles like Mechangelion. The pattern is consistent whether you are writing a guide or shipping a tutorial overlay.

Minute 0–3: teach the control model, not the lore

Players forgive thin story. They do not forgive unclear movement, aim, and special triggers. A first-session page should name:

Move / look / fire / skill cooldowns
What "stun," "overheat," or "guard break" means in this game
One safe drill (strafe + fire on a weak enemy) before the map opens up

A dedicated mech controls note beats burying binds inside a 2,000-word lore dump. Same for a first session guide: the job is a clean loop, not a completionist checklist.

If someone lands from search wanting to play immediately, send them to the playable shell — for example the Mechangelion play page — and keep the guide one tab away, not as a wall before the canvas.

Upgrade priority is a curriculum

Random shops teach learned helplessness. Early currency should buy survivability and clarity before vanity DPS:

Mobility or shield that reduces wipe chance on misplays
A primary weapon upgrade that shortens time-to-kill on trash
One utility that makes the upcoming boss readable (interrupt window, armor shred, heal on stagger)

A public upgrade priority page is content marketing that doubles as design documentation. If your live economy contradicts the guide after a patch, update the guide the same day — stale priority lists destroy trust faster than a hard boss.

Boss gates should examine the lesson

The first boss is a unit test for the tutorial:

Did the player learn the dodge / block / interrupt?
Does the telegraph read at browser latency?
Is failure informative (wrong upgrade, missed interrupt) or opaque (one-shot from offscreen)?

Document the gate the same way QA would: phases, tells, common wipe reasons. A focused boss fights write-up helps returning players more than a spoiler-heavy full walkthrough, and it gives you a place to patch notes when telegraphs change.

Pair that with a short beginner guide that stops before midgame nesting. Beginner ≠ encyclopedia.

Ops checklist for guide maintainers

Controls page updates when binds or mobile gestures change.
First-session page updates when the opening map or economy changes.
Upgrade priority updates on balance patches that touch early shops.
Boss page updates when phase order or tells change — not when a cosmetic skin ships.
Cross-link play → first session → upgrades → boss as a path, not a footer farm.

Why this matters for browser games specifically

HTML5 / WebGL titles compete with tab fatigue. A player who dies confused closes the tab; a player who dies understanding the mistake queues another run. Guides that mirror the real curriculum (controls → economy → boss exam) reduce bounce for the same reason good onboarding reduces churn in SaaS.

If you only publish one new page this month, make it the first-session spine. Everything else is a satellite.

Content Ops for a Small Game Wiki: Codes, Beginner, Walkthrough as Three Products

dylan yu — Thu, 15 Oct 2026 10:58:08 +0000

A fan wiki for a live game is not one article with three URLs. It is three products that share a domain: a status table, an onboarding spine, and a gated progression doc. Mixing them is how pages go stale, spoil new players, and burn editor time on the wrong refresh cycle.

I have been looking at how small teams keep 100 Days at Sea style sites honest without a newsroom. The workable pattern is to give each page type a job, a refresh SLA, and a hard rule about what it must not contain.

Product 1: the codes page is a status API in HTML

Promo codes rot on a weekly (sometimes daily) clock. The page's job is not inspiration. It is Active / Contested / Expired with a checked date. Redeem steps change rarely; status cells change often. Ops rule: rewrite cells, not essays.

That is why a maintained codes list should look boring on purpose. Flashy "NEW CODES!!!" banners train readers to distrust you when last week's string is still glowing. Keep Expired rows visible so dead codes stop getting reposted as fresh. If you need the method behind the labels, the verification note on how we verify codes is the editorial contract — not a second redeem tutorial.

Refresh SLA: short. Touch this page whenever a dump hits Discord or a major tracker updates. Do not wait for a "content calendar."

Product 2: the beginner guide is a Day-1 spine

Beginner pages fail when they try to be walkthroughs. New players need a resource triage and unlock order, not boss mechanics from week three. The job is: stabilize the raft, name the first stations, set a night-1 exit plan, then stop.

A focused beginner guide should refuse midgame spoilers the way a codes page refuses vibes. If a paragraph only helps after the first boss gate, it belongs elsewhere. Ops rule: update when the early economy or tutorial flow changes — not when a new late island ships.

Refresh SLA: medium. Patch notes that touch Day 1–3 matter; cosmetic seasons usually do not.

Product 3: the walkthrough is gated chapters

Walkthroughs exist for gates: prep checklists, failure modes, "you are blocked until X." They should be chaptered so a returning player can open one stretch without swallowing the whole plot. Spoiler boundaries are a product feature, not a courtesy.

Structure a walkthrough as spine mode documentation: when to follow, when to explore, what prep the next gate demands. Ops rule: update per gate when the encounter or recipe changes; do not reshuffle the whole TOC every week for SEO theater.

Refresh SLA: long per chapter, event-driven per patch.

Shared editorial rules that keep the three from collapsing

One primary job per URL. Codes do not teach Day-1 builds. Beginner does not list contested promo strings. Walkthrough does not bury a redeem form in chapter 1.
Timestamps match the job. Codes need a "checked" stamp. Beginner needs a "early-game verified as of" line. Walkthrough needs per-chapter patch notes.
Cross-link as handoffs, not keyword stuffing. Beginner → walkthrough when the raft is stable. Codes → beginner when someone is redeeming instead of eating. Walkthrough → codes only if a chapter is gated behind a seasonal reward.
Source methodology is public. A short source methodology page turns "trust us" into a checklist outsiders can audit.

Why this split helps SEO and humans

Search queries cluster by job: "codes," "beginner," "walkthrough / how to beat." One mega-page ranking for all three usually ranks cleanly for none after the first month, because refresh noise and spoiler complaints fight each other. Three products, three SLAs, one domain — that is content ops for a small game wiki, not a content calendar cosplay.

GAI vs FSIQ: How to Read the Gap Without Inventing a Story

dylan yu — Thu, 15 Oct 2026 10:56:44 +0000

A cognitive report that shows both a General Ability Index (GAI) and a Full Scale IQ (FSIQ) invites a tempting narrative: "I'm smarter than my IQ says" or "something is wrong with me." Most of the time the gap is a measurement pattern, not a personality plot. Here is how to read it without turning two numbers into a myth.

What each score is actually summarizing

FSIQ on a Wechsler battery folds in a broad set of index scores. GAI is built from a narrower set that leans harder on verbal and visual reasoning and usually puts less weight on working memory and processing speed. That is why GAI can sit above FSIQ when those secondary indexes are the drag — and why the reverse can happen too.

If you only remember one framing, use this: GAI is not a "true IQ" that FSIQ secretly underreports. It is a different composite with different inputs. A clear comparison of that design choice is in GAI IQ test vs a Wechsler, which is worth reading before you trust any online "GAI calculator" that never names its subtests.

Why GAI often looks higher

When working memory or processing speed are relatively weak, FSIQ drops more than GAI. The gap is then a signal about profile shape, not a prize. Parents and adults both over-index on the higher number because it feels kinder. Clinicians care about the shape because accommodations, pacing, and follow-up testing hang on it.

A practical explanation of that pattern — without cheerleading — is why GAI is higher than IQ. Pair it with the complementary piece on working memory, processing speed, and GAI if your report already shows those indexes. Reading both beats Googling "is a 12-point gap significant" in isolation.

How to calculate (and when not to)

If you have the scaled scores and a published conversion table for the exact battery and norms, you can compute GAI yourself. If you have only a marketing PDF and no table, you cannot. Wrong edition, wrong age band, or wrong combination of subtests produces a confident wrong number.

Use a transparent how to calculate GAI walkthrough when you want the arithmetic spelled out, then plug the same inputs into a GAI vs IQ calculator only as a check — never as a substitute for the official report. If the calculator and the report disagree, trust the report and ask the examiner which composite they used.

A sober reading checklist

Name the battery and edition. WAIS-IV / WISC-V / etc. are not interchangeable.
List which indexes feed GAI vs FSIQ on that edition. Do not assume last year's blog post matches your booklet.
Look at the gap direction and size, then at the indexes that explain it. A high GAI with slow processing speed is a different story from a flat profile with a tiny gap.
Refuse single-number identity. Neither GAI nor FSIQ is a career destiny or a moral score.
Ask what decision the score is for. Educational placement, clinical follow-up, and curiosity hobbyists need different levels of precision.

What "good" means in this context

People ask for a good GAI the way they ask for a good credit score. Composites are relative to a norm group, and "good" only makes sense relative to a purpose: gifted screening thresholds, discrepancy analysis, or simply understanding a classroom struggle. Absolute bragging rights are the least useful use of the page.

If you are staring at two numbers and feel the urge to pick a favorite, slow down. Read the composite definitions, check the calculation path, and treat the gap as a prompt to inspect working memory and speed — not as a plot twist about who you really are.

Retention Math for Ranking Shorts: Why the Order Beats the Template

dylan yu — Thu, 15 Oct 2026 10:55:16 +0000

Countdown Shorts look simple: five clips, big numbers, a beat drop. Most of them die in the first two seconds anyway. The failure is rarely the font. It is the order of the ranks and how much proof you put on screen before the viewer decides the list is fake.

I have been watching ranking Shorts the way a product person watches onboarding funnels. Same funnel, shorter clock. Here is the retention math that actually moves the needle, and where a purpose-built ranking workflow helps more than another CapCut template.

Second 0–2 is a claim, not a montage

Viewers do not "settle in." They ask: is this list going to be worth my thumb? A cold open that starts on Rank 5 with no claim wastes the only free attention you get. Lead with the promise: "Top 5 product fails from this week" or "Top 3 moments from one match." Then show Rank 5 or Rank 3 as evidence, not as throat-clearing.

A practical walkthrough of that claim-first structure lives in how to make a ranking short. Treat it as a checklist for the hook, not as decoration for the mid-roll.

Rank order is an information architecture problem

People argue about whether to count up or count down. Both can work. What kills retention is opaque criteria. If Rank 2 and Rank 1 look interchangeable, the audience stops caring who "won."

Write the ranking rule in one line before you edit:

Most rewatched moment in my own footage
Highest sales lift after a demo
Clearest skill expression in under four seconds

Then cut so that each rank visibly satisfies that rule. The on-screen number is a label. The clip has to earn it. When you are building a YouTube-facing countdown specifically, the platform habits differ slightly from Reels — pacing, end screens, and series hooks — which is why a dedicated YouTube Shorts countdown page is more useful than a generic "vertical video tips" post.

Retention is earned between ranks, not only at Rank 1

Creators obsess over the #1 slot and under-invest in the transitions. Drop-offs cluster when:

The next clip looks like the previous one (same angle, same length, same energy).
The lower ranks feel like filler so the top can look dramatic.
Text on screen contradicts what the clip shows.

A retention-oriented cut varies shot scale and proof type: reaction, result metric, before/after, failure, then payoff. If every rank is a 1.5-second slam cut of the same UI, the algorithm and the human both get bored. Notes on that mid-list retention pattern are collected in ranking short retention — useful when you already have clips and need a second pass on order, not another export preset.

Templates vs. ranking-native editors

CapCut-style templates give you motion. They do not give you a ranking model. If your workflow is "drop five clips into numbered slots, adjust labels, export," a ranking Shorts maker that treats ranks as first-class objects beats fighting a general timeline every time you reorder #4 and #2.

Reorder cost is the hidden tax. Every time you swap ranks in a linear timeline, you risk breaking transitions and captions. Ranking-native tools keep the claim, the number, and the clip bound together so reordering is a product action, not a re-edit.

A short production checklist

Write the one-line ranking rule.
Cut the cold open as a claim + Rank N evidence.
Make each rank satisfy the rule on screen, not only in your head.
Vary proof type between ranks.
Reorder in a ranking-aware editor before you polish motion graphics.

Countdown Shorts are not a genre of decoration. They are a tiny ranked list with a soundtrack. Get the list right first; the template will look smarter than it is.

How I Evaluate Free Web Tools Before I Trust a List

dylan yu — Thu, 15 Oct 2026 10:38:16 +0000

A free web tool is easy to open and easy to regret. Search "compress image" or "merge PDF" and you get lookalike sites: a thin form over someone else's API, or a signup wall on the third click. A directory only helps if it shrinks that choice. Here is the filter I use.

Start with the job, not the brand

Before I open a tab I write the task in one sentence: shrink this PNG under 200 KB, split a 40-page PDF, check contrast on a button, convert a HEIC from a phone. If a page cannot say which job it does, I close it. "Best tools" roundups fail that test.

I judge directories the same way. Categories named after the work beat a grid of logos. When I need one format turned into another, I open a converters list and compare options that claim the same job, instead of trusting the result that bought the top ad.

Five checks before a file goes in

Where the bytes go. If the file is not already public, I want it processed in the tab. When a tool uploads, I look for who receives it, how long they keep it, and whether the privacy page says so plainly. "We may use your content to improve our services" is a no for contracts, IDs, and unreleased designs.

Whether "free" survives one real run. I use my own file, not the demo. Watermarks, page caps, a download locked behind an account, and a quota that appears after the progress bar are part of the product. Holding the file hostage is not free.

Output I can ship. Compression that smears UI text, a merge that drops bookmarks, or a converter that strips the color profile can still "succeed." I compare size and a quick look at the original. If I cannot see what changed, I do not keep the tool.

No surprise install. A browser tool should stay in the browser. A desktop download, or an extension asking for broad permissions to convert one file, is a different product.

Someone still maintains it. A broken layout, a certificate warning, or a site untouched for years means it is rotting. Lists that never date their links become junk drawers.

What a useful list adds

A name and a favicon are not a review. A list I reuse names the constraint that matters — file size, local versus upload, account or not — and walks through one real task.

Before a hero image goes into a CMS I want that tradeoff spelled out: how hard to push quality, which format to leave with, and which sites stay in the tab. Compress images online without installing an app is more useful than a row of identical compressor cards, because it starts from the upload limit and only then names tools.

PDFs raise the bar. I will not install an app just to merge or shrink one, and I will not drop a client file on a random uploader. Free PDF tools you can use in the browser is the page I want: the task, why the tab is enough, and a few tools that claim to do it, with a reminder to check where the file goes.

The guide teaches the check. The category lets me swap tools when the first one fails. If a list never says when a link was last reviewed, I treat the top results as stale and re-test two of them myself.

A pocket checklist

One-sentence task.
Does the file stay in the browser? If not, would I send a non-sensitive sample?
Can I leave with the file after one run, with no second paid step?
Is the output good enough to ship, and can I see what changed?
Is the page maintained, and does the directory date its check?

If a directory helps me answer those without a dozen extra tabs, it has earned the bookmark. Web Tools List is organized as job categories plus short task guides, which is why I keep it bookmarked. Run the checklist on two tools the next time you convert a file.

Building an AI hairstyle try-on on third-party models: honest notes from EasyFace AI

dylan yu — Thu, 15 Oct 2026 00:14:57 +0000

I build EasyFace AI (https://easyfaceai.com), an AI hairstyle changer: upload one photo and preview a hairstyle, hair color, beard, face edit, headshot, outfit, or photo effect on that same person. This is a short note on how it is put together and what it honestly is and is not.

Third-party models, not a self-trained one

EasyFace does not train its own look model. Each feature routes to a third-party image model chosen for that job, and the feature names are listed publicly on the models page. I think being upfront about this matters more than sounding impressive. If you are deciding between this, a filter app, a photo editor, or a salon consult, I keep an honest comparison page that says when each option is the better pick.

Product decisions worth sharing

One free watermarked preview per visitor. It does not refresh daily, and creating an account does not add a second one. Simple rule, easy to explain.
Failed generations refund. A failed run returns the reserved credits and does not consume the free preview.
Short retention. The uploaded photo is deleted when the run finishes. Unpaid previews are deleted after 7 days, paid results after 30 days.
Face blur runs in the browser, so that photo is never uploaded.
It is a preview, not a promise. The result is a generated preview of one edit, not a haircut and not a medical image.

Content that answers the real question

Most people do not start with "AI hairstyle changer"; they start with "which haircut suits my face shape?". So I wrote a plain face shape and hairstyles table that maps oval, round, square, heart, long and diamond faces to cuts worth trying, which you can then try on your own photo.

Feedback welcome, especially on the comparison page: if something there is unfair to another option, tell me and I will fix it.

Content Ops for Seasonal Promo Codes on a Small Fan Site

dylan yu — Wed, 14 Oct 2026 12:53:38 +0000

Seasonal and weekly promo codes look like a content problem. They are really a publishing-ops problem: high churn, conflicting sources, and readers who punish you the first time a "working" string fails.

I have been reverse-engineering how small fan sites keep those pages useful without turning the author into a full-time list scraper. The pattern that works is a thin codes product, strict status rules, and deliberate links into the rest of the IA — not a weekly essay about the same redeem button.

Define the codes page as a status product

A codes URL should answer three questions and stop:

What is Active right now?
What is Contested, and why do sources disagree?
How do I redeem without getting scammed?

Everything else — early build order, island routes, Day-100 pacing — belongs on sibling pages. When a codes article grows a craft guide in the middle, both intents suffer: the status table gets buried, and the guide bits go stale on a different clock.

A clean example of the thin product is a dedicated Active / Contested / Expired codes table: short answer up top, full source-backed archive below, redeem steps once, FAQ for failure modes. No homepage funnel required.

Build a verification rubric you can defend

Readers do not need your vibes. They need a rubric you can repeat:

Active — ≥2 independent current lists agree live; none mark expired.
Contested — lists disagree; show each verdict in the row.
Expired — dated end from a source, with no later successful redeem reports.

Write the rubric on the page. When someone complains that Site A still shows a string as live, you point at Contested instead of arguing in comments. That single move turns drama into documentation.

Also record scope: "we reconcile public lists; we have not redeemed in-game" is a legitimate boundary. Over-claiming is how small sites lose the only asset they have — trust.

Run a fixed ops loop, not inspiration

Promo codes are calendar work. Pick a check window that matches the release pattern you observe (many games cluster drops on a weekday). Then run the same five steps every cycle:

Open the previous status table.
Diff against the trackers named in your Sources section.
Move rows between buckets with a one-line reason.
Bump the checked date (separate from publish date).
Refresh the short-answer blurb if the Active set changed.

Do not rewrite redeem steps weekly. Do not rewrite the FAQ unless the client UI changed. The diff is the article.

Keep a tiny changelog at the bottom ("Oct 14: added RIVAL to Active; SKELLY remains Contested because GamesRadar and RoCodes disagree"). Changelogs are cheap SEO and expensive trust.

Wire codes into the rest of the site without cannibalizing it

Codes pages get the spike traffic. Beginner and walkthrough pages get the depth. Link out from codes only where free currency changes a decision:

One line on the beginner page: claim an unused Active code before spending premium currency — then point at the early-build beginner guide for the spine that actually saves the first nights.
One line on the walkthrough: do not stall a run inside the redeem UI — then return to the checkpoint walkthrough for phase order.

Never paste the full status table onto those pages. Duplication guarantees drift. One canonical codes URL; everyone else deep-links.

SEO that survives churn

Head terms ("… codes October 2026") want a fresh checked date and an Active-only table above the fold. Long-tail terms ("why lists disagree", "contested vs expired", "code failed already used") want the method note and FAQ. Structure the HTML so both win:

H1 names the game + codes + month.
First screen answers Active count in plain language.
Tables for machines; paragraphs for disagreements.
FAQ mirrors the angry search queries people type after a failed redeem.

Avoid doorway pages that only exist to host affiliate junk or "code generators." Those patterns get you short spikes and long bans — on search engines and in community trust.

What good looks like after three months

Checked date stays within one release cycle. Contested rows still exist (if everything is Active, the rubric is fake). Beginner and walkthrough pages each deep-link to codes once — not the other way around as a dumping ground. Analytics show codes traffic converting into beginner sessions.

Takeaway

Seasonal promo codes are a status product with an ops loop: thin page, three-bucket rubric, checked timestamps, and deep links into beginner and walkthrough pages. Freshness is a process, not a vibe.

Information Architecture for Beginner vs Walkthrough Pages

dylan yu — Wed, 14 Oct 2026 12:50:10 +0000

Fan wikis keep shipping the same mistake: one giant "guide" that tries to be Day 1, mid-game, and endgame at once. Readers bounce. Authors dread updates. Search engines cannot tell which intent the URL serves.

The fix is boring and powerful. Split beginner from walkthrough as two products with different jobs, different tables, and different update cadences — then cross-link them on purpose.

Two jobs, two pages

A beginner page answers: what do I do in the first ten minutes so I do not wipe?
A walkthrough page answers: what are the checkpoints from stabilized start to the long milestone?

Mixing those jobs produces a scroll of tips with no spine. Separating them lets each page own one question and one primary table.

On a well-structured wiki you will see an early-build beginner guide that leads with a priority-ordered craft table (Bonfire tier → production building → passive food → map unlock), and a separate checkpoint walkthrough that leads with phase rows (stabilize → raft spine → short loops → boss prep → long push). Same site, different contracts with the reader.

Design the beginner page around executable order

Beginner IA should optimize for sequence, not lore.

Useful blocks, in this order:

Short answer — one paragraph naming the spine builds.
Priority table — build / unlock, approximate cost, why it comes first.
Day-1 checklist — numbered, boring, doable without a map.
Threat callouts — only the early killers that punish skipping the spine.
Where not to go yet — a hold list is as valuable as a go list.
FAQ keyed to first-session anxiety (what first, how to survive night one).

Costs belong in the table as community consensus, with an explicit "confirm in the craft menu" note. That single disclaimer keeps the page honest when patches move prices, and it teaches readers to trust the UI over any article — including yours.

What does not belong on the beginner page: full region lists, boss HP notes, or a Day-100 narrative. Those inflate the page and force weekly rewrites for content the early player will never reach.

Design the walkthrough as a checkpoint map

Walkthrough IA should optimize for phases, not recipes.

Useful blocks:

Checkpoint table — phase name, focus, do-this, skip-until-ready.
Phase path — each row links to the chapter that owns the detail.
Common wipe mistakes — negative space that prevents cargo-culting a YouTube full run.
FAQ about milestone timing, not Day-1 controls.

The walkthrough should point at the beginner spine instead of duplicating craft costs. When both pages list the same Sawmill recipe, one of them will drift after a patch and the site looks unreliable. Single source of truth for costs; walkthrough owns sequencing across the whole run.

Cross-links that respect intent

Linking is part of the architecture:

Beginner → walkthrough when the raft is stable and the reader asks "what next?"
Walkthrough → beginner for the Day-1 checklist and craft spine.
Both → a codes status page only where free currency actually changes early choices — usually a one-line aside, not a pasted table.

Avoid homepage dumps. Deep links to the page that owns the answer keep bounce low and make analytics readable: if /beginner-guide spikes after a patch that changed early unlocks, you know exactly which table to refresh.

Update cadence follows the split

Page type	Triggers a rewrite	Usually leave alone
Beginner	Craft costs, early unlock order, Day-1 threats	Late-region notes
Walkthrough	Phase ordering, raid windows, milestone rules	Exact recipe lines
Codes	Source disagreement, new/expired strings	Build order

This is content ops, not vibes. Smaller blast radius means you can ship a patch-day fix in twenty minutes instead of rewriting a 3,000-word mega-guide.

Naming and URL hygiene

Name pages after the job: /beginner-guide, /walkthrough, /codes. Avoid /guide and /tips — those collide in search and in the author's head. H1 should restate the job ("Early build order", "Checkpoints to Day 100") so both humans and crawlers know which intent won.

Takeaway

Beginner pages sell a first-session spine. Walkthrough pages sell a multi-phase map. Keep costs on one page, phases on the other, and use cross-links instead of copy-paste. The information architecture is the product; the tips are just cells in the tables.