If you share code on social media, you've probably used Carbon, ray.so, or Snappify at some point. They turn a snippet into a nice image, you download it, you post it. That's where they stop.

The thing I kept running into wasn't generating the image — it was everything around it. I'd write a snippet I wanted to post, but not right now. I'd tweak the colors, get it looking good, then have nowhere to put it. Next time I needed it, it was gone, and I'd start over.

So I built Snipworth: a Chrome extension that turns code into polished images, but treats the snippet itself as something worth keeping. It's on the Chrome Web Store at v1.1.0, open-source under MIT.

Why build yet another code-screenshot tool?

Two reasons, honestly.

The first was practical. I post code on X and LinkedIn fairly often, and the generate-download-post loop never fit how I actually work. I wanted a place to draft snippets — write one now, refine it later, keep a few around just for myself — instead of treating every image as throwaway.

The second was learning. I had never built a browser extension, never touched Manifest V3, never published anything on the Chrome Web Store. Rather than a throwaway tutorial project, I picked a real problem I had and built the whole thing end to end — domain model, UI, export pipeline, CI, store submission.

The existing landscape looked like this:

• Carbon / ray.so — great-looking output, web-based, but stateless. No library, no persistence, nothing social-media-aware beyond the image.
• Snappify — feature-rich and polished, but commercial and account-based.
• Editor extensions (CodeSnap & co.) — handy inside one editor, but tied to it.

The gap I went for: an open-source, local-first browser extension where generating the image is just one step, and the real product is managing your snippets — code, image, caption, hashtags, target platform, all kept together.

What does it do?

Snipworth lives in a Chrome side panel that stays open while you browse, and in a full-tab mode for when you want room to work. Both run the exact same React app.

Capture code from anywhere

Paste a snippet, or select code on any page, right-click, and hit "Snipworth this code". It lands in the editor ready to style.

Syntax highlighting + language auto-detection

Highlighting is powered by Shiki, so you get VS Code-grade themes. The language is auto-detected, with a one-click override when the guess is wrong. The UI shows the language actually used.

One-click formatting

A single click runs Prettier over your snippet — JavaScript/TSX, JSON, CSS, HTML, Markdown, YAML, GraphQL, and more. Messy paste in, clean snippet out.

Style it, then export

Theme (dark/light), monospace font, size, background, padding — all adjustable with a live preview. When it's ready, copy straight to the clipboard or download as PNG or SVG at 1×, 2×, or 4×.

The library — the part I actually built this for

Every snippet can be saved as a draft. The library is a grid of everything you've kept: filter by platform, language, status, or tags; archive the ones you're done with; come back and refine the rest. Post them when you're ready, or just keep them around — a personal shelf of code you liked.

Social-media presets

Each draft carries a target platform with the right preset baked in — dimensions, aspect ratio, character limit — plus a caption and hashtags. Pick X, LinkedIn, Instagram, story, or thread, and the export comes out at the correct size for that feed.

Your data is yours

Everything is stored locally in IndexedDB — no account, no server, no tracking, nothing leaves your browser. And you can export your whole library to a JSON file to back it up or move it to another machine.

How it works under the hood

The interesting part of this project wasn't any single feature — it was trying to build it as cleanly as I could. I used Snipworth as an excuse to apply Clean Architecture and Domain-Driven Design properly, on a real codebase, instead of just reading about them.

The dependency rule

The code is split into four layers, and source-code dependencies only ever point inward:

infrastructure → adapters → application → domain

• domain/ — the heart. The Draft aggregate, value objects, business rules. Zero imports from anything outside: no React, no Dexie, no chrome.*, no Shiki. It doesn't know it's running in a browser.
• application/ — use cases, one per user-meaningful action (SaveCurrentEditorAsDraft, CopySnippetAsImage, UpdateDraft…). They orchestrate the domain and talk to the outside world only through ports.
• adapters/ — the implementations of those ports. Shiki, html-to-image, Dexie, the clipboard, chrome.* — every concrete technology lives here.
• infrastructure/ — wiring and bootstrap.

Everything external is a port

The domain and use cases never call a library directly. They depend on small interfaces they define themselves — SyntaxHighlighter, FontPreloader, ImageExporter, DraftRepository, ClipboardCopier, plus Clock and IdGenerator so time and IDs are injected rather than ambient.

This paid off in concrete ways:

• The side panel and full tab share one bundle — there's a single source of truth for behavior, and nothing UI-specific leaks into the core.
• Swapping a technology is an adapter change, not a rewrite. If I ever replace html-to-image, or move off Shiki, the domain doesn't notice. (The same goes for a future Firefox port — the chrome.* calls are all behind adapters.)
• I can test the whole application without booting a browser. Use cases run against hand-written fakes for the ports and an in-memory IndexedDB. The tests describe behavior ("when a draft is saved, it can be found again"), not implementation, so they survive refactors.

Where MV3 constraints met the architecture

A few Manifest V3 realities shaped the port boundaries in ways I didn't expect:

• Clipboard copy must preserve the user gesture. If you await the rendered blob before constructing the ClipboardItem, the gesture has expired and the copy silently fails. The trick is to hand the Promise<Blob> directly to ClipboardItem — so the ClipboardCopier port is shaped around a promise, not a resolved blob.
• Fonts must be preloaded before every export, or the first image of a session renders with system fallback fonts. That's a FontPreloader port the export use case always calls first.
• Highlighting goes HAST → React elements, never an HTML string. Shiki returns a syntax tree; the UI converts it to React nodes. Safe by construction — no dangerouslySetInnerHTML anywhere.
• The service worker keeps no long-lived state. MV3 kills it after ~30s idle, so anything that needs to survive goes to IndexedDB or chrome.storage. The worker is a router, nothing more.

What I learned

This was my first extension, my first Manifest V3 project, and my first Chrome Web Store submission. A few things stood out.

Manifest V3's CSP means everything is bundled

No remote code. At all. Shiki grammars, themes, the WOFF2 fonts, Prettier — all shipped inside the extension. No <script src="https://…">, no dynamic import() against a URL. It's a real constraint, but it also means the extension works fully offline.

Shiki without WebAssembly

Shiki normally uses an Oniguruma WASM regex engine. That would have forced wasm-unsafe-eval into the manifest and added ~600 KB. I switched to Shiki's pure-JS regex engine instead — slightly slower on dense grammars, but no WASM, a smaller bundle, and a cleaner manifest. I lazy-load grammars and themes on demand so the core install stays light.

The architecture earned its keep

I went in worried the layering would feel like overkill for an extension. It didn't. The moment the side panel and full tab needed to share logic, the moment I wanted to test export without rendering an actual image, the moment an MV3 quirk needed to be quarantined in one place — the boundaries were already there. Discipline up front, less thrash later.

Test the behavior, not the wiring

I leaned on sociable tests through the use cases — real domain objects, hand-written fakes only for the ports — instead of mocking everything. The suite reads like a spec and doesn't shatter every time I move a method. That, more than anything, kept the refactors cheap.

Try it out

If you post code on social media, give it a try:

• Chrome Web Store: Snipworth
• GitHub: Alex9583/Snipworth

It's open-source, free, local-first, and I'm actively working on it. If something's missing, broken, or could be better — open an issue or drop a comment. It's still early, and feedback genuinely helps.

If you want to support the project, you can buy me a coffee ☕.