DEV Community: river

I Edited Text in an AI Poster—Then Checked What Else Changed

river — Wed, 14 Oct 2026 09:32:00 +0000

The moon was right. The colors were right. Even the tiny event details were right. The headline was the one thing that needed to change: NIGHT BLOOM had to become AFTER DARK.

This is a controlled poster example from our EditableImage text-editing workflow, not a client campaign. Regenerating the entire frame would throw away the parts we wanted to keep. So the useful question wasn't “Can AI write the new words?” It was: Can we change those words without quietly changing everything around them?

Before: NIGHT BLOOM	After: AFTER DARK

Only the headline was meant to change. The moon, vines, gradient, and small event details were meant to stay put.

The test I care about is outside the edit

A side-by-side comparison can miss subtle drift. A model might make the moon slightly smaller, move a leaf, or rewrite the event time while fixing the headline. Those are failures when the surrounding design is the part you wanted to preserve.

For this test, we marked the headline, generated replacement lettering, and composited only the marked result onto the original image. We then compared the two versions pixel by pixel. The image below is an annotated change map, not the finished poster:

Orange marks the old “NIGHT BLOOM” lettering; blue marks the new “AFTER DARK” lettering. The two phrases overlap because they occupy the same part of the poster, so this map is not meant to be read as a headline. The dimmed background is shown only for reference.

On the web-compressed examples above, the meaningful differences occupy under 4% of the frame, all in the headline area. The comparison ignores faint compression noise (up to 22/255 here). The downloadable editor result is a lossless PNG; outside the selected lines, it retains the original pixels. The 4% figure describes this poster, not a promise for every image.

That distinction matters. “Looks similar” is subjective. “Nothing outside the marked area changed” is a property you can check.

A practical check for your own image

You don't need a special tool to apply the same reasoning:

Keep the original file. Compare against that file, not a screenshot of it.
Align dimensions. If the output was resized or cropped, a pixel diff will light up everywhere and tell you little.
Mark the allowed region. Decide before editing which pixels may change. For this poster, it's the headline; for a product screenshot, it might be one button label.
Look outside that region. Any substantial change there deserves an explanation. If you're comparing JPEG or WebP copies, first allow for compression noise; use lossless exports when you can.
Zoom in at 100%. The diff can tell you where pixels changed, but not whether the new lettering has a clean edge or a believable font.

The same test is especially useful for an approved UI screenshot with an outdated button label or a campaign image with last month's date. The design around the words is not disposable just because the words are wrong.

Where the result can still disappoint

Keeping the original outside the marked lines creates a trade-off at the boundary. On a smooth gradient like this poster, the seam is hard to notice. On a photograph, grain, or a busy pattern, the newly inferred background behind old letters may not join perfectly with the original. A full-image redraw can hide that seam, but it can also shift details elsewhere. Neither mode is universally better; compare both at full resolution.

This also doesn't recover an original font file. The new lettering is drawn to resemble the surrounding type; an exact font match isn't guaranteed. If the lettering is the artwork—a hand-painted logo, for example—I would rebuild it manually rather than expect a text edit to preserve its character.

My takeaway from this poster isn't that AI can “fix any image.” It's a narrower, more useful rule: when one part of an image is wrong, define the permitted change and inspect everything outside it. That turns a plausible-looking edit into one you can actually evaluate.

The full poster case and its limitations are on our site. If you want to try the same bounded edit on your own asset, here's the text-editing workflow.

The Mermaid Flowchart Rendered—but the Failure Path Was Missing

river — Wed, 14 Oct 2026 03:38:31 +0000

A deployment flowchart went from a red parser error to a clean, exportable diagram—but the most important fix was not syntax. Mermaid Online identified two concrete code errors; the preview then exposed a missing failure path. Below is the exact before-and-after, with screenshots and the code you can adapt.

This is a small, reproducible walkthrough, not a production incident. The point is to show where the tool saves time and where a human still has to decide what the arrows mean.

The starting draft

The intended flow was simple: push to main, build an image, run smoke tests, then deploy only if they pass. Here is the deliberately flawed first version:

flowchart LR
  A[Push to main] --> B[Build image (v2.4)]
  B --> C{Smoke tests pass?} C -->|yes| D[Deploy to prod (us-west)]

Pasting this into the Mermaid syntax checker produced a parse error on line 2. The opening parenthesis in “Build image (v2.4)” was being read as Mermaid syntax rather than label text. The smallest repair was to quote the label:

A["Push to main"] --> B["Build image (v2.4)"]

That did not finish the job. The next check reached line 3 and stopped at the second C: two statements had been squeezed onto one line. Its unexpected-token clue was NODE_STRING. Splitting the edge and the yes branch onto separate lines fixed that error.

Example of the checker's line-level feedback. The full code for this walkthrough is shown above and below.

The useful lesson is that the first parser error is not necessarily the only one. Fix the reported line, run the parser again, and keep the rest of the diagram intact. A wholesale rewrite can accidentally change the process you meant to document.

A green check was not the finish line

Once the code parsed, the live preview made the larger problem obvious. The decision diamond had a yes route to production and no route for a failed smoke test. That is not a Mermaid error. A parser cannot infer your release policy.

An earlier preview of the yes-only version: syntactically valid, but the failure path is absent.

For this example, a failed test should send the team to investigate and push a fix before the build runs again. The diagram also needs to show what happens after deployment. Here is the complete tested version:

flowchart LR
  A["Push to main"] --> B["Build image (v2.4)"]
  B --> C{"Smoke tests pass?"}
  C -->|yes| D["Deploy to prod (us-west)"]
  C -->|no| E["Investigate and push fix"]
  E --> A
  D --> F["Monitor"]

The final diagram exported from the exact code above. The no route returns through a fix and a new push; the yes route continues to deployment and monitoring.

It passes the checker and renders with both branches visible. The return arrow goes to Push to main, not straight back to Build image: this example assumes a new code change is needed before retrying. If your team reruns a flaky test without a new commit, that arrow should be different. The diagram is useful only if the arrows describe the real procedure.

Getting it into the document

A valid preview is still not the same thing as a deliverable. For this case, the Mermaid Online editor’s export panel produced a 2× PNG in the Clean Docs standard style. The page reported a 2452 × 672 px file with no watermark. The same panel offers SVG, PDF, and other image formats; the core checker and standard-style exports do not require an account.

The destination decides what to keep:

In a GitHub README that supports Mermaid, keep the source code. Reviewers can diff a changed edge and future editors can fix a label without recreating an image.
In a slide deck or document that will not render Mermaid, use SVG when it is supported or a high-resolution PNG when compatibility matters. Keep the source beside the exported asset so the image does not become the only copy of the diagram.

The layout choice matters too. A long pipeline can become an awkward vertical strip with top-down direction. Left-to-right worked better for this example, but it made the exported image wide. A slide may need fewer nodes or two smaller diagrams rather than a tiny unreadable one.

The same steps can read very differently depending on direction and where the diagram will live.

That is the workflow Mermaid Online makes less fiddly: paste code, get a concrete parser error, inspect the rendered flow, and export a clean asset. It shortened the mechanical part of this example. It did not decide that the no branch was missing, or whether a failed test should lead to a retry, rollback, or manual review. Those remain the author's decisions.

The next time a generated diagram gives you a red banner, fix the first reported token. When it turns green, ask the harder question: what would a teammate misunderstand if they used this diagram to do the job? For more on prompt constraints and other Mermaid failure modes, there is a longer guide here.

A Checkerboard Is Not Transparency: A Practical Alpha Test for Video

river — Fri, 09 Oct 2026 07:24:06 +0000

You export a “background-free” video, put it on a web page, and see a black rectangle. Is the file broken? Perhaps. But the player might be ignoring a real alpha channel.

Before running background removal again, separate three things: the preview background, the file's alpha channel, and the software playing the file. They can produce similar-looking screenshots for very different reasons.

Start with a no-code test

Place the exported file above a bright, solid-color layer in a video editor that supports transparency. Change that layer to a very different color. Watch the space around the subject, then pause on frames with hair, hands, or motion blur.

If both colors show through around the subject, the file is being composited with transparency in that editor.
If you see a fixed checkerboard, black, or white rectangle, either those pixels are baked into the file or the current playback path is not displaying alpha. Try a second known-compatible destination before blaming the removal step.
If the background changes but the edges look poor, alpha is present; your problem is cutout quality, not format support.

This visual test tells you what the destination can display. It does not prove every application will handle the same file in the same way.

What the checkerboard actually means

The grey-and-white checkerboard is a visual convention used by editors to represent empty space. It is not transparency itself. If those squares are written into the exported video, you have an opaque video of a checkerboard.

An alpha channel stores opacity alongside color. At one pixel, alpha 0 means the background can show through; alpha 1 means the foreground is fully opaque. Values in between let hair, glass, or motion-blurred edges blend with whatever is underneath. Apple’s ProRes white paper describes alpha as the data used to composite a foreground image over a background.

That is why the test uses two contrasting backgrounds and the actual exported file, rather than accepting one preview screenshot as proof.

A tiny browser test for VP9-alpha WebM

Save this as alpha-test.html next to your exported cutout.webm, then open it in a browser that supports VP9 alpha. Replace the filename if yours is different.

<div class="stage" id="stage">
  <video autoplay muted loop playsinline>
    <source src="cutout.webm" type="video/webm">
  </video>
</div>
<button id="switch-bg">Switch background</button>

<style>
  .stage { background: #14223b; width: min(100%, 720px); }
  .stage.light { background: #f2e8d5; }
  .stage video { display: block; width: 100%; }
</style>
<script>
  const stage = document.querySelector('#stage');
  document.querySelector('#switch-bg').addEventListener('click', () => {
    stage.classList.toggle('light');
  });
</script>

If the area around the subject switches from navy to cream, this browser is compositing the video over the page. Inspect the edges as well as the empty areas. If a solid rectangle remains, the file may be opaque—or the browser may not support this alpha path. Test in another alpha-aware destination before re-exporting. MDN's video codec guide notes that Safari does not support alpha transparency in VP9.

If the video does not play at all, check that the filename, path, and codec are correct before interpreting the result as an alpha failure.

Why a real transparent background matters

A cutout with a working alpha channel is reusable footage, not just a video that looks clean against one chosen color. You can place the same person or object over different website sections, slide backgrounds, or editing timelines without removing the background again for each design. That is especially useful when a campaign's colors change after the footage has already been prepared.

The practical advantage is flexibility: export once in a format your destination supports, then composite the subject over the background that fits the project. A baked-in checkerboard or solid-color rectangle takes that flexibility away.

A preview of the workflow—and what to verify

The BG Remover Online example shows a processed 3.75-second, 1920×1080 clip. The page identifies its 90-frame output as VP9-alpha WebM, and lets you switch the preview among checkerboard, blue, and dark backgrounds. You can try those controls without uploading anything. Seeing the same cutout on contrasting backgrounds helps you judge whether its edges will work in more than one design—not just whether it looks good on a checkerboard.

A separate outdoor result makes the comparison easier to see. This Product Hunt gallery image uses the same processed frame against three preview backgrounds:

Source footage: Pexels. These are preview composites, not three different exports or proof about the downloaded file.

Both demonstrations are still site previews. The cover image shows its original frame next to the cutout on a checkerboard; the cover alone cannot verify the alpha channel in a downloaded file. For your own project, export your clip and run the two-background test above in the destination that matters to you. The source footage is from Mixkit; the person shown is not affiliated with the product.

When a “transparent” file looks black

I diagnose the problem in this order:

Check the actual output format. An ordinary H.264 MP4 is not an alpha-delivery file for this workflow. Renaming .mp4 to .webm does not add opacity data.
Test a known alpha-aware editor or browser. If the background layer shows through there, your original player is the likely limitation.
Switch between light and dark backgrounds. One color may conceal halos, missing hair, or a leftover matte.
Inspect multiple frames. A clean still can shimmer when the subject moves.
Only then re-export. If the file fails in more than one compatible destination, choose an alpha-capable export and verify the new file before delivery.

Pick the format for the destination

There is no single transparent-video format that is ideal everywhere.

Destination	Practical choice	Caveat
Supported web playback and overlays	WebM with VP9 alpha	Test the target browser; Safari does not display VP9 alpha.
Editing and compositing	ProRes 4444	Large files; an alpha channel is supported but must actually be present in the export.
Compatible Apple playback	HEVC with alpha	A distinct alpha-capable HEVC workflow, not an ordinary MP4 export.

Apple documents ProRes 4444 alpha support and HEVC with alpha. Choose based on where the file will be used, then verify the actual output, not only the codec name.

If you use BG Remover Online for that test, its current limits are worth knowing first: video uploads are capped at 60 seconds; it exports VP9-alpha WebM, and offers ProRes 4444 for processed clips up to 15 seconds. It does not currently export HEVC alpha or retain the original audio. Google sign-in gives new accounts 5 free credits—enough for five images or up to five started seconds of video, with no card. Uploads are private: an upload you never process is deleted after 24 hours, and finished results are kept for 7 days and can be deleted sooner. Check the current terms before uploading sensitive footage.

If you need a subject you can reuse over different backgrounds, try BG Remover Online with a short, non-sensitive clip. Switch the preview background to inspect the edges, download the transparent video, then test that file in your actual editor or browser. The result is valuable when it saves a reshoot or a second cutout—not merely when the preview looks convincing.

The general rule is tool-independent: a checkerboard preview is a prompt to test, not evidence that the file will composite where you need it.

Disclosure: I built BG Remover Online. AI assistance was used to draft and edit this article; product-specific details were checked against its public pages. The public preview is described as a preview, not as an independent inspection of the downloaded file.

A PPTX Is Not Necessarily an Editable Slide: Five Tests That Matter

river — Fri, 09 Oct 2026 07:22:43 +0000

A screenshot pasted onto a PowerPoint slide is technically a .pptx. It is also still just a screenshot. You can resize it, but you cannot rewrite the title, move a KPI card, or correct a number without rebuilding part of the slide.

That distinction matters when the original deck has disappeared and the only surviving copy is a PNG in a wiki, a PDF export, or a screenshot in a chat thread. The useful question is not “Can I get a PPTX?” It is “Which edits will the downloaded PPTX actually let me make?”

Here is a five-part test you can run on any image-to-slide workflow. The point is to test the exported file, not just trust a polished preview.

1. Can you change the words as words?

Click the main title and replace one word. Then try a small label, such as a KPI value or footnote.

If the text is a native text box, you should be able to select characters and change the copy. If the output merely puts a new text box over old text baked into the background, the old letters may reappear when the replacement is shorter. Move the text box temporarily and inspect what is underneath.

Typography is a second test. A converter may recognize the correct words but substitute a font, weight, or line break. That is recoverable, but it is still review work.

2. Do the pieces move independently?

Try moving the title, one card, and the chart region. If the whole slide moves together, the file is mostly an image inside a PPTX wrapper.

There is an important distinction inside this test: a chart that moves as one graphic is not necessarily a native PowerPoint chart with an editable data table. Likewise, a recovered icon might be an independent image rather than a vector shape. Decide what level of editing you need before judging the export:

What you need to do	Minimum useful result
Rewrite a heading	Native text box
Reposition a visual	Separate slide object
Recolor individual parts	Editable shapes or layers
Change chart values	Native chart data or a deliberate redraw

“Editable” is a spectrum, not a single checkbox.

3. What appears when you move an object away?

This is the test that polished before/after pictures often skip.

Move the title to an empty corner. Is there a clean background underneath, or is the old title still visible? Move a card. Does it leave a rectangular hole or a blurry patch?

Reconstructing the background behind a foreground element requires an educated guess: the original pixels were covered. On a plain gradient that may be easy. On a photograph or intricate texture, expect to inspect and possibly repair the fill. Keep the original image beside the reconstructed slide so you can spot changes.

4. Did the small details keep their meaning?

A slide can look convincing at a glance while getting a tiny but important detail wrong: a percentage, axis label, date, unit, legend entry, or footnote. Compare each one against the source image. Pay extra attention to low-resolution text and labels placed over busy imagery.

For data-heavy slides, I treat the converted file as a draft until the numbers have been checked by a human. Visual similarity is not the same as factual accuracy.

5. Does it survive a round trip?

Download the PPTX, close the web editor, and open the file in the PowerPoint application your team actually uses. Make one text edit and one layout edit there. Check for substituted fonts, shifted objects, or a slide that became flat during export.

This matters because an interactive browser preview can demonstrate the intended structure without proving that the downloaded file preserves it.

Why convert an image to editable PowerPoint?

Imagine you inherit this “Genetic Discovery” slide as a single image and need to update its explanation for a new audience. Rebuilding the two-column layout, charts, and labels by hand would take time before you could even start editing the message. In the original image, none of those elements can be selected independently.

Before: a flattened slide image.

The next screenshot shows the slide in EditableImage’s Image to PPT editor. A text region in the right-hand panel is selected as a separate object. The visual layout is still recognizable, but there is now a starting point for changing copy and rearranging parts of the slide instead of recreating everything from a blank canvas.

After: a text object selected in the browser editor. This is not a screenshot of the exported PPTX opened in PowerPoint.

That is the practical value of an image-to-editable-PowerPoint workflow: it can turn a screenshot-only slide into a reconstruction draft you can work from. For an old presentation that needs a revised heading, a corrected paragraph, or a new arrangement, the time saved comes from not having to redraw the whole slide first. The original remains beside the result, making it easier to spot what needs fixing.

The trade-off is visible too: some dense text in this result is garbled or overlaps nearby content. Check every scientific label and number against the source before reuse. These screenshots show object separation in the browser editor; they do not prove that chart values are native PowerPoint data, that every background is clean, or that the exported PPTX passes the round-trip test.

If you have a slide you actually need to revise, try converting one image with EditableImage. Correct the obvious text errors, export the PPTX, and run the five tests above. Judge it by the manual work it saves on your slide—not by a perfect-looking preview.

A short test with your own slide

If you have a screenshot-only slide, use a full-resolution PNG, JPG, or WebP rather than a compressed chat thumbnail. Then:

Write down two edits you actually need to make—for example, change a KPI and move a card.
Convert that one slide and compare the result with the original. Fix obvious recognition errors before export.
Download the PPTX and run tests 1–5 in PowerPoint. Keep the source image next to it while you inspect small details.
Judge the result by manual work avoided, not by the number of objects reported. If your requirement is editable chart data or an exact licensed typeface, expect to rebuild or supply those parts yourself.

For context, the current EditableImage workflow requires sign-in, uses 4 credits per slide conversion, and gives new accounts 10 free credits without a card. The page estimates 45–90 seconds for processing. Images are sent to third-party AI services, are not published, and are deleted after 24 hours. Check the current terms before uploading anything confidential.

If all you need is a slide that looks right, simply placing the screenshot on a slide may be enough. If you need to reuse its words and layout, the exported file—not its extension or its preview—is the evidence.

Disclosure: I built EditableImage. AI assistance was used to draft and edit this article; the product details above were checked against its public pages. I have not presented the browser preview as an independent test of every exported PPTX.

I Recovered an Architecture Diagram from a PNG—Every Box Came Back, but the Labels Lied

river — Sun, 27 Sep 2026 15:15:52 +0000

When the only copy of an architecture diagram is an image, you can recover it as an
editable Draw.io file instead of redrawing it: the boxes and their labels come back as
real shapes you can move, and the arrows come back as connectors. On the real example
below, every box and every arrow came back — but the small words written along the arrows
did not, and a few of them came back wrong. It is a draft to check, and this post is about
what exactly to check.

How does a diagram end up as only a picture?

The usual ways. A design session ends and someone photographs the whiteboard. A system is
explained once in a slide deck, and the deck survives while the source file does not. A
PNG gets pasted into the wiki by the person who then leaves. Six months later the diagram
is needed for a review, it gets redrawn from memory, and the redraw gets a detail wrong
that nobody can check.

A picture cannot be searched, diffed against next quarter's design, or edited when the
system changes. A diagram file can.

What does "recovered" mean?

Not a trace. Image to Draw.io measures the boxes from the pixels, reads
the labels, follows the arrow strokes, and attaches each connector to the shapes it joins.
The result behaves like a diagram: drag a node and its edges go with it, retype a service
name in place, export Draw.io XML that opens anywhere
mxGraph files are read.

The diagram at the top of this post went in as a flat image. This is what came back:

The recovered diagram in the editor. The panel on the right counts what came back: 13 nodes, 12 connectors, 13 labels.

What did it get right, and what did it miss?

Most of it. Taken from the recovered file itself — which boxes each connector is actually
attached to, not how it happens to be drawn:

Every box came back, in its place, with its label and its fill colour: the eleven services and stores, plus the version tag and the sticky note. The three data stores came back as cylinders.
All twelve connectors are joined to the right two boxes. The nine arrows point the right way, and the three plain lines down to the data stores stayed plain lines.
The dashed "production vpc" boundary is gone, and its label with it. The boxes it grouped are all there, just no longer inside anything.
The words on the lines are the weak part. The original has six. One came back right (grpc), three came back missing (https, rest, sql), and two came back as words the original does not have: get / set became redis, and events became kafka.

Those last two are the ones worth dwelling on. They are plausible — a cache next to the
word redis, a message queue next to kafka — which is exactly why they are easy to miss. A
missing label is obvious; a wrong one that sounds right is not. The smaller slips are of
the same kind: the tag's "·" came back as ":", and some rounded corners came back square.

So the check that matters is not "does it look like the original", which it largely does.
It is: read every word on a line against the original, then drag each box and watch which
lines come with it. The original stays one click away in the editor for exactly this
comparison, and each fix is a retype or a drag rather than a redraw.

Is a whiteboard photo harder?

Yes. The example above is a clean export, which is the easy input — and it still needed its
line labels checked, which is worth saying plainly, because a clean export is the one every
tool in this category shows. A photographed board adds a
perspective the lens was not square to, a light reflection across some of the writing, and
hand-drawn boxes without the consistent borders box detection leans on.

Clear structure — boxes with borders, arrows with arrowheads, one label per edge — gives
the best start. Dense freehand sketching comes back as a rougher draft with more arrows to
fix. Either way the boxes and labels are the part you do not have to retype, and ten
minutes of dragging connectors beats redrawing the whole thing from memory.
Whiteboard photo to diagram covers how to photograph a
board so it can be read.

The steps

Open Image to Draw.io and upload the picture.
Read every label on a line against the original, then drag each box and watch which lines come with it: is every arrow there, joined to the right two boxes, pointing the right way?
Fix what is wrong by reconnecting, dragging and retyping.
Export the XML and put it where the next person will find it — versioned, searchable, and checkable against the next redesign.

Questions

What does it produce?

Standard Draw.io XML — nodes, connectors and labels that open in diagrams.net and any tool that reads mxGraph files.

Will the connectors follow the nodes?

They come back as edges attached to shapes, so dragging a node carries its arrows with it — which is also the quickest way to find an arrow attached to the wrong shape. Check every edge is there, joins the right two boxes, and points the right way.

Does it work on photographed whiteboards?

When boxes and arrows are clear, yes. A photo is a harder input than a clean export, so expect more to correct — the whiteboard page covers how to photograph a board so it can be read.

Archify Online: Interactive Diagrams in Your Browser, No Agent Needed

river — Mon, 21 Sep 2026 10:10:00 +0000

You see the screenshots everywhere: architecture maps that light up a request path on click, fade everything else back, and let you walk a system layer by layer. They come from Archify — the open-source diagram project on GitHub (tt-a1i/archify), MIT-licensed — which has collected more than 65,000 stars since April 2026 (as of September 2026). Then you open the repository and hit the catch: Archify is not a website. It is an agent skill and a CLI, meant to live inside Claude Code, Codex, or a similar tool.

Most people searching for "Archify online" want the maps, not the tooling around them. This post covers what Archify actually is, whether an official online version exists (short answer: no — by explicit design), and the browser port of the same engine that we run at mermaidonline.org — including what carries over, what had to change, and an honest comparison so you can pick the right form for your workflow.

TL;DR

Archify is a 65,000+-star open-source engine that turns a system description into a verifiable, interactive map — but it ships as an agent skill/CLI, not a website.

There is no official hosted version; the README names hosted sharing as intentionally out of scope.

We ported the same MIT-licensed rendering engine to the browser: paste a description, a Mermaid flowchart, docker-compose, Terraform, Kubernetes, or SQL, and explore the result at the interactive map generator.

Export is a self-contained HTML file — search, route tracing, and lenses keep working offline, in one file you can attach to a PR.

What Is Archify and Why Is It Everywhere?

Archify is best understood as a compile step for system diagrams. Instead of asking a model to "draw" boxes and hoping the output is legible, an agent produces a typed JSON intermediate representation of your system, and Archify deterministically compiles that specification into self-contained HTML/SVG. The project's own README puts it simply: agents produce the typed specification; Archify deterministically renders it (project README on GitHub, accessed September 2026). That split is why the output looks designed rather than generated — layout, routing, and label spacing are rules, not guesses.

It landed at the right moment. AI coding agents became the default place where engineers already describe systems, so "turn a codebase or system description into a polished, interactive system map — directly in chat" (project README) matched how people actually work. Growth has been steep: the repository was created in April 2026, crossed roughly 22,800 stars by late August, and sits above 65,000 as of September 2026 (GitHub repository and public star trackers).

Item	Details
Project	tt-a1i/archify on GitHub
License	MIT
Form	Agent skill + CLI (runs inside coding agents)
Diagram types	Architecture, workflow, sequence, data flow, lifecycle
Created	April 2026 — 65,000+ stars as of September 2026

The mental model to keep: Archify is a skill you install into your agent, not a site you visit. Which raises the obvious question.

Is There an Official Archify Online Version?

No — and this is a deliberate scope decision, not an oversight. The README states it verbatim:

"Automatic Mermaid parsing, general-purpose auto-layout, hosted sharing, and WYSIWYG editing are intentionally outside the current scope." (project README on GitHub, accessed September 2026)

The official site is a documentation landing page plus a gallery of pre-built example artifacts you can download and open locally. Nothing on it accepts your input and returns a map. So today there are exactly two ways to run this engine:

	How it works
Original (official)	Install the skill into an agent (Claude Code, Codex, Cursor, …), describe your system in chat, receive the rendered map locally
Browser port (ours)	Open a web page, paste code or describe the system, explore the map immediately

Everything below is about the second row — what a browser port of the engine gives you, and where it deliberately differs.

A Browser Port of the Same Engine: No Install, No Agent

We run the ported engine at the interactive map generator. One disclosure first: Mermaid Online is not affiliated with or endorsed by the Archify authors — we ported its MIT-licensed engine and credit it by name in the product.

What carries over from the original

The part of Archify that makes the output good is the deterministic layer, and that is exactly what the port preserves. Same typed JSON specification contract, same rule-driven layout and label-fitting, same interaction model: click a node to focus it, press R to trace an exact route between two nodes, L to compare semantic roles through lenses, P to play a guided story, search with /. Deep links carry state — a URL fragment like #route=a~b reopens the map with that path already traced. Because the compilation is deterministic, the same specification renders identically in the CLI and in the browser; route traces over the same nodes return the same hops. The exported artifact is the same self-contained HTML file: one file, no CDN, no server, and the interactions keep working offline.

What we rebuilt for the browser

The upstream flow assumes an agent sits in front of the engine: you describe the system in chat, the agent authors the JSON specification. In a browser there is no agent, so our service takes over that step — an AI layer converts your input into the typed specification, and the renderer takes it from there. That substitution drives most of the practical differences below, including the inputs we accept (the original explicitly excludes automatic Mermaid parsing, while accepting a pasted Mermaid diagram is one of our primary paths). It also changes the economics: running the conversion costs us model calls, so the port is free for your first 10 maps and uses credits after that, while the CLI remains fully free under its MIT license.

From Mermaid, docker-compose, Terraform, K8s, or SQL to an Interactive Map

The input story is where the port diverges most from upstream. The original expects your agent to read a repository or a chat description; Mermaid parsing is explicitly out of its scope. Our conversion layer was built for exactly the artifacts engineers already have lying around:

Input	Original Archify	Browser port
Plain-English description	✅ (in agent chat)	✅
Mermaid flowchart	❌ (out of scope by design)	✅ paste it
docker-compose / Terraform / K8s manifests	❌	✅ paste it
SQL schema	❌	✅ paste it

Paste a Mermaid flowchart

This is the path most mermaidonline readers will care about. Take a flowchart you already maintain:

flowchart TD
    A[Client] --> B[API Gateway]
    B --> C[Webhook Service]
    C --> D{Delivery ok?}
    D -- yes --> E[(Event Store)]
    D -- no --> F[Retry Queue]
    F --> C

Paste it into the interactive map generator, and the conversion layer maps nodes to typed components, classifies them (external, backend, message bus, data store), and hands the specification to the same deterministic renderer:

The static diagram did not change — the same six nodes and edges are all there. What changed is that every box became an addressable object you can search, trace, and filter. If your Mermaid does not render cleanly to begin with, fix that first with our guide to getting AI-generated Mermaid to render correctly, or generate fresh code with the AI Mermaid generator. Photos of whiteboards work too — turn a whiteboard photo into Mermaid first, then paste the result. And if a static Mermaid architecture diagram is all you need, the Mermaid architecture diagram guide covers that path.

Paste infrastructure as code

The same conversion layer reads infrastructure definitions. A docker-compose.yml becomes services and their dependencies; a Terraform file becomes managed resources and their references; Kubernetes manifests become workloads, config, and the clusters they expose. The value over reading the YAML is the same as with Mermaid: the map exposes structure — what calls what, what happens if this node dies — which is tedious to reconstruct by eye from a few hundred lines of manifests.

Point it at a SQL schema

Foreign keys are edges; tables are nodes. A schema paste produces a map where you can trace exactly which tables a given feature touches — useful during migrations and reviews, when the question "what reads this table?" needs a precise answer. As with every input mode, the result is an explorable map, not a picture.

What the Map Can Do: Node Search, Route Tracing, Lenses, Guided Stories

The interactions are the reason to bother with an engine like this at all. Four of them carry most of the value:

Node search (/) jumps the viewport to any named node — the fast path in a map with dozens of components.
Route tracing (R) asks the only question that matters in an incident review: how does a request actually get from A to B? The map highlights the exact directed hops and fades everything else.

Semantic lenses (L) re-color the map by component role — backends, data stores, external services — so you can read one layer at a time.

Guided stories (P) play an authored walkthrough of the system, one step at a time — the closest thing to a presenter mode a generated map has.

Two of these survive export in a shareable form. Deep links like #route= and #lens= reopen the exported HTML with the view already applied, which makes them surprisingly useful in PR descriptions and design docs — paste a link and reviewers see the path you are talking about, not a red rectangle drawn on a screenshot. For destinations that cannot run HTML at all, export a static PNG when the destination can't run HTML instead; and if you are weighing interactive HTML against plain Mermaid blocks, how Mermaid renders in GitHub README files covers the trade-offs.

60-Second Walkthrough: Mermaid Flowchart to Interactive Map

Open the interactive map generator — no install, no signup to try.
Paste a Mermaid flowchart, docker-compose, Terraform, Kubernetes, or SQL — or just describe the system in plain English. The input type is detected automatically.
Generate. The map renders in the page; search (/) for a node name to test that everything landed.
Press R and pick two nodes to trace a route; press L to view the map through a role lens.
Download the self-contained HTML — it opens offline with every interaction intact.

That is the whole loop. There is nothing to configure before step 2; the type chips (Architecture, Dataflow, Sequence) exist if you want to force a diagram style instead of relying on detection.

Honest Comparison: Browser Port vs the Original Archify CLI

If you are evaluating this family of tools, the comparison that matters is not "port versus original" as a quality ranking — the port uses the original's engine. It is which form fits your workflow:

	Original Archify (agent skill/CLI)	Browser port (mermaidonline.org)
Price	Free (MIT)	10 free maps, then paid credits
Install	Agent + skill/CLI	None — a browser tab
Diagram types	5 (incl. workflow, lifecycle)	3 (architecture, dataflow, sequence)
Inputs	Whatever your agent can read (repos, chats)	Description or pasted Mermaid / compose / Terraform / K8s / SQL
Output	Self-contained interactive HTML	Same engine, same self-contained HTML
Reproducibility	Spec + deterministic compile	Spec + deterministic compile

When the original CLI is the better choice

If you already live in Claude Code or Codex, the skill is the more natural home: it can read your repository directly, it is free without limits, and it tracks upstream immediately. You also get the two diagram types the port does not serve yet — workflow and lifecycle — plus whatever the fast-moving upstream adds next (the project has shipped continuously since April).

Limitations of our port

The port covers three of the five diagram types; upstream updates reach it only when we re-port them; the input conversion runs through our AI layer rather than your local agent; and after the first 10 free maps it is paid credits. None of that is hidden in the fine print — it is the trade you make for zero install. If those constraints bite, use the original; that is what it is for. And if the interactive layer is more than you need, a well-structured static diagram still goes a long way — keeping large diagrams readable applies regardless of the render.

Frequently Asked Questions

Is Archify free to use?

The upstream project is MIT-licensed open source, so the CLI and agent skill cost nothing. Our browser port is free to try with no account — you get 10 interactive renders, and paid credits cover heavier use.

Does Archify have an official online version?

No. As of September 2026, the project README states that hosted sharing is "intentionally outside the current scope", and the official site hosts documentation plus a gallery of prebuilt examples. The only way to run the engine in a browser today is a third-party port like ours.

Can I use Archify without an AI agent or CLI?

The original Archify is an agent skill and CLI designed to run inside tools like Claude Code. Our port moves the rendering engine into the browser, so you can paste Mermaid, docker-compose, Terraform, Kubernetes manifests, or a SQL schema and get an interactive map with nothing to install.

What export formats does Archify support?

The core output is a self-contained interactive HTML file that works offline — node search, route tracing, and lenses keep functioning in the exported file. If you need a static image for slides or docs, you can export one with our Mermaid-to-PNG tool instead.

Try It While You Are Here

Everything above runs at mermaidonline.org — the interactive map generator needs no account for your first 10 maps, and the same site covers the static side of the workflow: generating Mermaid from a description or an image, checking syntax, and exporting PNG/SVG. If you end up preferring the original CLI, the repository README has the install instructions — the engine is the same either way; pick the form that matches where you work.

“Looks done” is not the same as launch-ready

river — Wed, 17 Jun 2026 09:35:43 +0000

I used to check small sites in a pretty shallow way before launch.

Open the homepage.

Click the main CTA.

Resize the browser.

Make sure nothing looks obviously broken.

If the page looked fine, I shipped it.

But the issues I kept missing were rarely visual.

A staging noindex tag was still there.

The canonical URL pointed to a preview domain.

A privacy or contact link returned 404.

The sitemap included old test pages.

The shared link preview looked broken.

The homepage copy was clear to me, but not clear enough for someone seeing it cold.

None of these are dramatic bugs.

But they matter because launch traffic usually comes in a short window. You post once on Product Hunt, Reddit, HN, a newsletter, or send the link to users. That first impression is shaped by more than the hero section.

So my pre-launch check changed.

Now I try to answer a few boring but useful questions:

Can search engines index the right pages?
Are canonical, sitemap, and robots signals consistent?
Do trust links like privacy, terms, and contact actually work?
Does the page explain what the product is and who it’s for?
Does the link preview look reasonable when shared?
Are there any leftover staging or test signals?
For AI/devtool sites: is there enough public context for an assistant to summarize it correctly?

That last one is becoming more important for me.

I don’t think anyone can honestly promise “AI visibility.” But many sites accidentally make themselves harder to understand: thin copy, missing docs, blocked crawlers, placeholder llms.txt, unclear positioning.

Before sharing a site now, I try to ask:

If someone — or some crawler — sees this page without context, will they understand it correctly?

I turned this checklist into a small free tool here:

WebsiteReady launch checker

But the habit is the useful part:

Don’t only check whether the site looks finished.

Check whether it is ready to be discovered, shared, indexed, and trusted.

I wanted cleaner beautiful Mermaid diagrams for docs, so I made a small exporter

river — Thu, 04 Jun 2026 07:56:46 +0000

I use Mermaid diagrams a lot when I am trying to explain something that is easier to see than to read.

A release flow. A service talking to another service. A small state machine. The kind of diagram that belongs in a README, an architecture note, or a planning doc.

Mermaid itself is great for that. Plain text, versionable, reviewable. The part that kept annoying me was what happened after the diagram looked right.

I often wanted a clean image for a README, a slide, or a blog post. Not a rough screenshot. Not something with awkward padding. Not a diagram that looked fine in one place and slightly blurry everywhere else.

So I made a small tool for that:

Mermaid Online

It is a browser-based Mermaid editor and exporter. Paste Mermaid code, preview it, adjust the export style, then download PNG, SVG, JPG, WebP, or PDF.

No signup. No watermark. The core render/export workflow happens in the browser.

The problem I wanted to smooth out

Here is a tiny example:

flowchart LR
  A[Write the doc] --> B[Sketch the flow]
  B --> C[Preview the diagram]
  C --> D[Export for README]
  C --> E[Export for slides]

That is easy enough to write.

But when I need to put it somewhere, I usually start making small judgement calls:

Should this be SVG or PNG?
Does it need a transparent background?
Is 1x too soft for a slide?
How much padding should the diagram have?
Will it still be readable in a GitHub README?

None of these are hard problems. That is partly why they are annoying. They are small enough that I do not want to open a design tool, but visible enough that a sloppy export makes the whole doc feel less cared for.

What Mermaid Online does

The tool is intentionally simple.

You paste or edit Mermaid code on the left, check the live preview, then choose the export format and style.

The formats I cared about most:

PNG for README files, docs, and slides
SVG when I want a vector asset
PDF for handoff or document workflows
WebP for lightweight blog images
JPG when I need the boring compatible option

There are also presets for common destinations: clean docs, GitHub README, transparent backgrounds, dark docs, slides, and blog-style cards.

That last bit matters more than I expected. A diagram for a README and a diagram for a presentation usually should not have exactly the same padding, background, and scale.

A workflow that feels right to me

For documentation, I usually do this:

Write the Mermaid diagram directly while working on the doc.
Paste it into Mermaid Online.
Use a docs or README preset.
Export PNG at 2x, or SVG if the destination handles it well.
Put both the Mermaid source and exported asset near the doc.

For slides, I usually switch to a transparent preset and export at a larger scale. That keeps labels and arrows sharper on big screens, especially when the diagram gets resized by the slide tool.

For blog posts, WebP is nice when I want something lighter, and the editorial-style preset gives the diagram enough breathing room that it does not look like a raw screenshot dropped into the middle of the page.

Why local-first mattered

Some Mermaid diagrams are harmless. Others describe internal systems, database relationships, release flows, or security-review details.

I did not want the default workflow to require uploading diagram text just to turn it into an image.

The core editor and exporter run in the browser, so the diagram content stays local during the normal export path. That makes the tool feel more appropriate for architecture notes and internal docs.

It is still a small project, so I am being careful with the wording here: this is an independent tool, not affiliated with Mermaid.js, Mermaid Chart, or their maintainers.

What I would like to improve next

The current version is mostly about single-diagram export quality.

The things I keep thinking about next are:

Batch export from Markdown files
ZIP downloads for multiple diagrams
Saved custom themes
Better workflows for docs teams
More examples for common architecture and product diagrams

I am deliberately not rushing all of that in at once. The first version should do one job well: turn Mermaid code into a clean asset you can actually use.

Try it

If you use Mermaid in README files, technical docs, slides, or blog posts, you can try it here:

https://mermaidonline.org/

I would especially like feedback from people who write docs often:

Which export format do you use most?
Do you prefer keeping Mermaid source in the doc, or committing generated images?
What diagram style actually looks good inside your documentation system?

Small tools get better when they are shaped by real workflows, so practical feedback is more useful to me than general praise.