DEV Community: Suradet PS

CodeFrame: Turning Source Code Into Beautiful Images, Right In Your Browser

Suradet PS — Sat, 15 Aug 2026 04:00:15 +0000

Every developer who has ever needed to share code in a slide deck, a blog post, or a GitHub issue has reached for the same two tools: a screenshot, or a manual copy into a presentation tool. Screenshots are blurry and fixed-size. Manual copies lose syntax highlighting and formatting. And the popular web tools that render code to images? They cap out at 2x, because they're secretly taking screenshots of the DOM.

That's the problem CodeFrame solves.

What is CodeFrame?

CodeFrame is a web app that converts source code into high-resolution PNG (or SVG) images, in the style of carbon.now.sh and ray.so, but with one hard architectural difference: it never screenshots the DOM.

Under the hood, it uses:

Canvas2D rendering via WebAssembly: every token is drawn pixel-by-pixel with fillText, at whatever scale you ask for
syntect (the same engine behind Sublime Text's syntax highlighting) compiled to WASM with the fancy-regex backend
7 bundled themes: Dracula, One Dark, Nord, GitHub Light, Tokyo Night, Catppuccin Mocha, Monokai
3 bundled monospace fonts: JetBrains Mono, Fira Code, Cascadia Code
Zero backend: no server, no accounts, no telemetry. Your code never leaves your browser

use codeframe_renderer::layout::{compute_layout, Layout};
use codeframe_renderer::draw;
use codeframe_models::ExportOptions;

let options = ExportOptions {
    scale: 4.0,          // user-selectable, not capped at 2x
    padding: 48.0,
    window_frame: true,
    line_numbers: true,
    ..ExportOptions::default()
};

// draw(ctx, tokens, palette, options) paints the whole card:
// background -> frame -> traffic lights -> token text -> line numbers

That's the whole point. No DOM screenshotting. No html2canvas. No resolution ceiling.

Why not just screenshot the page?

You absolutely can. But here's what you're accepting:

Your resolution is capped at devicePixelRatio (typically 2x, occasionally 3x). A 2x screenshot of a 1200px-wide card gives you 2400px. CodeFrame gives you 8x (or custom scales up to 12x) because the canvas backing store is created at full size: canvas.width = logical_width * scale, then one ctx.scale() call, and everything draws in logical coordinates.
Fonts get rasterized at 2x too: text edges stay soft no matter how much you "upscale" later. fillText on a canvas at 8x produces genuinely crisp glyph edges.
Backgrounds, shadows, and gradients are baked in: a screenshot captures whatever the browser happened to composite, including scrollbars, focus rings, and cursor blink states.

CodeFrame draws the entire card from scratch: background gradient, rounded card, macOS traffic lights, padding, and one fillText per token with the exact theme colors. The output is deterministic: the same input always produces the same image.

The resolution rules (the core differentiator)

These four rules are load-bearing:

Canvas pixel size = logical size × export_scale, computed up-front, never rendered small and upscaled later.
Export scale is user-selectable: 1x, 2x, 4x, 8x, or a custom value, with a "target width" mode that computes the scale for you (1200px for Twitter, 1920px for a slide).
Preview and export use separate canvases. The preview renders at a screen-friendly scale (capped at 2x, clamped against devicePixelRatio) so typing stays smooth; a fresh full-scale canvas is created only when the export button is pressed.
document.fonts.ready is awaited before every draw (preview and export), so a not-yet-loaded font can never silently fall back to a system font mid-export.

canvas.set_width((logical_width * scale) as u32);
canvas.set_height((logical_height * scale) as u32);
ctx.scale(scale, scale)?; // draw in normal logical coordinates from here on

And exports use canvas.toBlob("image/png"), never toDataURL. At 8x, the PNG can be tens of megabytes in memory; toDataURL would base64-encode the whole buffer, wasting roughly a third of your memory for no reason.

Rendering layer order

Every frame is drawn bottom-to-top in a fixed order:

1. Background gradient or solid color
2. Code card: rounded rect + drop shadow
3. macOS traffic-light dots (if window frame is on)
4. Padding area
5. Token text: fillText per token, x-cursor advanced manually
6. Line numbers

Note step 5: text wrapping is not left to the browser. Each token's width is measured, the cursor advances by exactly the glyph widths, and the renderer controls every pixel. That's what makes the output identical at 1x and 8x.

A live editor that mirrors the export

CodeFrame's code input is a full syntax-highlighted editor: a transparent-text textarea overlaid on a <pre> rendered from the same syntect token stream that drives the canvas. What you type matches what you export, down to the theme's exact colors:

use codeframe_highlighter::highlight_to_html;
use codeframe_models::{Language, ThemeChoice};

let html = highlight_to_html(
    "fn main() {}",
    Language::Rust,
    ThemeChoice::Dracula,
)?;
// <span style="color:#ff79c6;">fn</span><span ...> main() {}</span>

The editor background and caret color come from the theme palette itself, so switching from Dracula to GitHub Light restyles the whole input box. Both layers share identical font metrics, wrapping rules, and scroll positions, so the highlight is always pixel-aligned with the caret.

Beyond PNG: SVG, split screens, and presets

SVG export: the same layout math emits <text>/<tspan> elements, so the result scales infinitely for docs and slides.
Split-screen comparison: two code panels side-by-side, each with its own code, theme, and language, exported as a single image.
Copy to clipboard: one click puts the PNG on the clipboard for pasting straight into Slack or Figma.
Background presets: snow white, top glow, bottom glow, left beam, right beam, plus padding, corner radius, line height, and font-size controls, all live.

Why the crate boundaries matter

CodeFrame is a Cargo workspace with four crates, split so the hard parts are testable without a browser:

models ──► highlighter ──► renderer
   │            │              │
   └────────────┴──────────────┘
                │
                ▼
               app

models: shared types (Token, ExportOptions, Background), zero dependencies beyond serde
highlighter: wraps syntect; takes &str + Language and returns Vec<Token>
renderer: pure canvas-drawing logic; the layout math has no web-sys at all and is fully unit-tested
app: the only crate that knows Leptos: components, signals, event handlers

The token stream is the contract: highlighter produces it, renderer consumes it, and a browser test can't accidentally hide a bug that unit tests would catch.

When NOT to use CodeFrame

CodeFrame is designed for presenting short snippets: a function, a config block, a diff. It's not suited for:

Screenshots of real UIs: it's a drawing engine, not a DOM capture tool
Long documents: it renders a single card; a whole file export is better done with a real editor
Animated code: output is a static image (that's the point)
Server-side generation: everything runs in the browser, by design. No headless Chrome, no server rendering

The pipeline

code string
    |
    v
syntect (WASM, fancy-regex backend)
    |
    v
Vec<Token>  (text + color + font style)
    |
    v
layout.rs  (pure math: measure, wrap, position)
    |
    v
Canvas2D fillText per token  ──►  PNG blob (toBlob)
    |                              └──► download / clipboard
    └──► same tokens ──► SVG <text> elements

Highlighting: syntect with default-fancy; the C onig backend doesn't compile to wasm32, so the pure-Rust fancy-regex backend is the only portable option
Rendering: Canvas2D via web-sys (full pixel control, no DOM screenshots)
Export: separate high-scale canvas + toBlob, not toDataURL
Fonts: Web Font Loading API; document.fonts.ready is checked on every draw

Final thoughts

CodeFrame intentionally focuses on one thing: code to image, at the highest resolution the browser can draw, instead of becoming another screenshot utility. If all you need is a beautiful, crisp code image for your slides, your docs, or your README, it gives you a focused, opinionated workflow while doing the rendering the right way: pixel by pixel, in WASM.

The stack covers the whole story:

✅ Real canvas rendering (no DOM screenshots, no html2canvas)
✅ Export up to 8x (custom scales supported)
✅ 7 syntax themes, 3 bundled fonts, 15 languages
✅ SVG export + split-screen comparison
✅ Live syntax-highlighted editor mirroring the export
✅ Offline-first PWA (service worker, installable)
✅ Zero server, zero tracking: code never leaves the browser
✅ Built with Rust + Leptos + Trunk, compiled to WASM

Paste some code and export.

Credit & Reference

Encrypting Secrets in Rust Without Writing Crypto Glue Code

Suradet PS — Fri, 24 Jul 2026 08:54:38 +0000

Every Rust developer who needs application-level encryption eventually reaches for crates like aes-gcm or chacha20poly1305. Those crates provide excellent cryptographic primitives - but building a complete encryption workflow still means deciding how to derive keys, generate nonces, encode ciphertext, and store master keys safely.

That's the problem encryptman solves.

What is encryptman?

encryptman is a Rust crate that gives you a dead-simple API for encrypting and decrypting strings - passwords, API keys, tokens, anything you'd rather not store in plaintext.

Under the hood, it uses:

AES-256-GCM for authenticated encryption (confidentiality + integrity)
HKDF-SHA256 for deriving purpose-specific keys from a single master key
Random 12-byte nonces - encrypting the same plaintext twice yields different ciphertexts
Zeroize on drop - master key memory is wiped automatically

use encryptman::{encrypt, decrypt, generate_master_key};

let master_key = generate_master_key();

let ciphertext = encrypt(&master_key, "my_database_password")?;
let plaintext = decrypt(&master_key, &ciphertext)?;

assert_eq!(plaintext, "my_database_password");

That's it. No algorithm selection. No nonce management. No encoding headaches.

Why not just use aes-gcm directly?

You absolutely can. But here's what you'll need to handle yourself:

Key derivation from a master key (HKDF setup)
Random nonce generation per encryption call
Base64 encoding for safe storage
Zeroizing key material from memory
Version byte for future algorithm migration
Context isolation to prevent cross-domain ciphertext substitution

encryptman bundles all of this into a single, well-documented API with missing_docs = "deny" enforcing complete documentation.

Context isolation

One feature that's easy to overlook: encryptman supports context strings for HKDF key derivation. Different contexts produce different subkeys from the same master key, so ciphertext from one domain can't be decrypted in another. Contexts are implemented using HKDF domain separation rather than additional encryption metadata.

use encryptman::{encrypt_with_context, decrypt_with_context, generate_master_key};

let key = generate_master_key();

// Database passwords
let db_ct = encrypt_with_context(&key, "database", "postgres://secret")?;

// API keys
let api_ct = encrypt_with_context(&key, "api-keys", "sk-12345")?;

// Same plaintext, different contexts -> different ciphertext
assert_ne!(db_ct, api_ct);

// Cross-context decryption fails
assert!(decrypt_with_context(&key, "database", &api_ct).is_err());

This prevents a whole class of attacks where an attacker swaps ciphertexts between unrelated parts of your application.

URL-safe encoding

Need to put encrypted values in JWTs, cookies, or URLs? encryptman has you covered with Encoding::UrlSafeNoPad:

use encryptman::{encrypt_with_encoding, decrypt_with_encoding, generate_master_key, Encoding};

let key = generate_master_key();

let encrypted = encrypt_with_encoding(&key, "jwt", "token", Encoding::UrlSafeNoPad)?;
let decrypted = decrypt_with_encoding(&key, "jwt", &encrypted, Encoding::UrlSafeNoPad)?;

assert_eq!(decrypted, "token");

No more worrying about + and / characters breaking your URLs.

The key storage problem

Here's where things get interesting. encryptman handles encryption beautifully, but it doesn't solve the next question: where do you store the master key?

The README says "use an OS keychain or KMS" - but that still means writing platform-specific code. This is where encryptman-keyring comes in.

encryptman-keyring: Zero file management

encryptman-keyring is a companion crate that stores the master key directly in your OS native credential store:

Platform	Credential Store
Windows	Credential Manager
macOS	Keychain
Linux	Secret Service (DBus)

One call. No key files. No .env headaches. Applications never access the raw master key directly unless they explicitly request it.

use encryptman_keyring::Vault;

// First call: generates key -> stores in OS keychain
// Later calls: loads existing key from keychain
let vault = Vault::new("my-app")?;

let encrypted = vault.encrypt("my_database_password")?;
let decrypted = vault.decrypt(&encrypted)?;

assert_eq!(decrypted, "my_database_password");

The service name ("my-app") doubles as the HKDF context, so different applications automatically get domain isolation.

The architecture looks like this:

                Application
                     |
                     v
          encryptman-keyring
                     |
      +--------------+--------------+
      v              v              v
   Windows       macOS Keychain   Secret Service
   Credential
   Manager

Multiple contexts with one vault

use encryptman_keyring::Vault;

let vault = Vault::new("my-app")?;

let db_secret = vault.encrypt_with_context("database", "postgres://...")?;
let api_secret = vault.encrypt_with_context("api-keys", "sk-12345")?;

assert_ne!(db_secret, api_secret);

let db_plain = vault.decrypt_with_context("database", &db_secret)?;

Separating environments

Need different keys for dev and production? Use new_with_target:

use encryptman_keyring::Vault;

let dev_vault = Vault::new_with_target("my-app", "development")?;
let prod_vault = Vault::new_with_target("my-app", "production")?;

Each target stores a separate key in the OS keychain under the same service name.

Migrating from key files

Already have .key files lying around? Import them and delete the originals in one step:

use encryptman_keyring::Vault;

let vault = Vault::migrate_from_file("my-app", std::path::Path::new("/path/to/.key"))?;
// File is deleted after successful migration

Typical use cases

encryptman is designed for application-level secrets such as:

Database connection strings
API keys
OAuth refresh tokens
SMTP credentials
Third-party service secrets
Local application configuration

When NOT to use these crates

encryptman is designed for encrypting small strings - passwords, API keys, tokens. It's not suited for:

Password hashing - use argon2 or bcrypt
File encryption - use a streaming encryption library instead of encrypting the whole file in memory
Database-at-rest encryption - use your database's built-in encryption (TDE, disk encryption, etc.)
Large data - the entire plaintext is held in memory

encryptman-keyring isn't ideal for:

Headless/CI environments - OS keychain may not be available
Multi-user servers - keyring entries are per-user; consider Vault or AWS Secrets Manager

The pipeline

master key
    |
    v
HKDF-SHA256("encryptman:{context}")
    |
    v
AES-256-GCM key
    |
    v
plaintext + random nonce
    |
    v
ciphertext
    |
    v
version || nonce || ciphertext
    |
    v
Base64

Key Derivation: HKDF-SHA256 generates domain-separated subkeys
Authenticated Encryption: AES-256-GCM detects any tampering
Fresh Nonce: 12 random bytes per encryption call
Version Byte: Reserved for future algorithm migrations

Final thoughts

encryptman intentionally focuses on application secrets rather than exposing low-level cryptographic primitives. If all you need is to encrypt configuration values, API tokens, or passwords, it provides a simple, opinionated API while following modern cryptographic practices.

The ecosystem covers the full workflow:

✅ AES-256-GCM authenticated encryption
✅ HKDF-SHA256 key derivation
✅ Context isolation
✅ OS keychain integration (no key files)
✅ URL-safe encoding for JWTs/cookies
✅ Zeroize on drop
✅ MSRV: Rust 1.85 (Edition 2024)

Just generate a key and start encrypting.