DEV Community: ProvChart

Building a Lightweight Portfolio Dashboard with ProvChart & st-core Tokens

FSCSS tutorial — Fri, 11 Sep 2026 15:49:34 +0000

Open-source template: github.com/Figsh/dashboard-project

Most dashboard tutorials start the same way: pull in 40–150 KB of JavaScript, wait for hydration, and hope search engines eventually see the chart.

We wanted the opposite.

This is a dark portfolio dashboard that:

Renders charts with zero charting JavaScript on the page
Uses ProvChart to turn data into pure HTML + CSS
Keeps the original st-core.fscss design tokens for a consistent, high-end look
Stays crawlable, fast on first paint, and easy to theme

This article walks through how it was built and how you can reuse the template.

The problem with typical chart libraries

Approach	Cost	First paint	SEO / crawl
JS Libs	40–150 KB+ JS	After hydration	Often missed
Hand-written CSS charts	Fragile, limited points	Instant	Good
ProvChart	0 KB chart runtime	Instant	Excellent

ProvChart compiles your data into CSS custom properties and returns scoped HTML + CSS. The browser paints the shape with native CSS (clip-path, gradients, etc.). No chart library ships to the client.

Stack overview

ProvChart API — POST /api/v1/generate → { html, css }
st-core tokens — the same CSS variables used by st-core.fscss
Vite — fast local dev and simple build
Tiny Node proxy — keeps the API key off the browser

Design tokens stay exactly as they were:

:root {
  --st-bg:       #080710;
  --st-surface:  #0f0e1c;
  --st-card:     #13122a;
  --st-accent:   #6c47ff;
  --st-accent-2: #a78bff;
  --st-green:    #00e5a0;
  --st-red:      #ff4d6a;
  --st-text:     #edeaff;
  --st-muted:    #5e5a82;
  --st-border:   rgba(108, 71, 255, 0.13);
}

The UI (sidebar, KPIs, allocation bars, activity feed, profile dropdown) is pure CSS on top of these tokens. Charts are the only part that talks to an external service.

How ProvChart is wired in

1. Server-side proxy (key stays private)

// api/proxy-server.js (simplified)
const res = await fetch('https://provchart-api.devtem.org/api/v1/generate', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    'X-API-Key': process.env.PROVCHART_API_KEY,
  },
  body: JSON.stringify(payload),
});

The browser only calls /api/chart. Never expose a live key in frontend bundles.

2. Client payload (real numbers, not 0–100)

{
  type: 'area',
  theme: 'midnight',
  height: 260,
  axisX: ['Mon', 'Tue', 'Wed', 'Thu', 'Fri', 'Sat', 'Sun', 'Mon', 'Now'],
  series: [
    { name: 'Portfolio', color: '#6c47ff', points: [74200, 76800, …, 84201] },
    { name: 'Benchmark', color: '#00c9b8', points: [72800, 74500, …, 81000] },
  ],
  legend: true,
  grid: true,
}

ProvChart auto-formats large values (20K, 1.3K, 2M, 1.09B…). You send raw numbers; you do not pre-format with k / M / B.

3. Inject HTML + CSS

const { html, css } = await res.json();
host.innerHTML = html;
// each chart gets its own <style> so instances never clobber each other

Each host (#main-chart-host, #spark-btc-host, …) keeps a scoped style tag. That avoids the classic “last chart wins and the others go blank” bug.

Data shape: 9 points, clear narrative

Instead of 24 noisy points, every series uses 9 points with a deliberate arc:

Downfall — a clear dip
High rate — a strong recovery into “Now”

Example (1W portfolio):

portfolio: [74200, 76800, 75500, 72800, 71500, 76200, 79800, 82500, 84201]
//          Mon     Tue    Wed    Thu    Fri    Sat    Sun    Mon    Now
//                         ↘ dip ─────────↗ strong climb

Labels stay short and aligned (Mon … Now). No client-side slicing or thinning.

Dashboard features in the template

Period tabs: 1D / 1W / 1M / 3M / 1Y (each re-requests ProvChart)
KPI row + overview stats strip
Main multi-series area chart (Portfolio vs Benchmark)
BTC / ETH spark area charts
Allocation bars + recent activity feed
Sidebar with profile dropdown
Live clock, responsive layout, same st-core visual language

Everything is vanilla JS modules + CSS. No React/Vue required.

Getting started

git clone https://github.com/Figsh/dashboard-project.git
cd dashboard-project
npm install

cp .env.example .env
# or export PROVCHART_API_KEY="your_api_key"
# add PROVCHART_API_KEY from https://chart.devtem.org/dashboard

# Terminal 1 — proxy
npm run proxy

# Terminal 2 — Vite
npm run dev

Open http://localhost:5173.

Free tier note: ProvChart free accounts get a small number of generations per month.

Why this approach works

First paint — charts appear with the CSS; no wait for a chart library.
Bundle size — zero charting JS on the page.
Crawlability — the chart structure is real HTML.
Theme control — st-core tokens + ProvChart theme: "midnight" keep the look consistent.
Security — API key only lives on the proxy / edge function.

You still get dynamic period switching and multi-series visuals; you just don’t pay the usual JavaScript tax.

Repo & next steps

Template: github.com/Figsh/dashboard-project
ProvChart: chart.devtem.org
st-core.fscss: underlying token/chart primitives used by the design system

Fork it, swap the datasets, point the proxy at your own backend, or pre-generate SVGs with the ProvChart GitHub Action for static docs.

Lightweight dashboards don’t have to look lightweight. With ProvChart and a solid token set, they can look like a product — and still load like a static page.

Generate pure CSS charts from Claude (or any MCP client)

FSCSS tutorial — Mon, 31 Aug 2026 08:18:10 +0000

Ask an agent for a chart today and it'll usually hand you a Chart.js config, or some SVG with hand-typed coordinates. Fine to look at in a chat window, but the moment you actually want it somewhere real, a README, a docs page, a landing page, you're back to pasting code into a sandbox, while the real UI still needed JS libs (or a screenshot).

So ProvChart now has an MCP server: the agent calls a tool and gets back real HTML/CSS or SVG, not a sketch of one.

Package

Tools

Tool	Output
`provchart_generate`	`html` + `css`
`provchart_generate_svg`	`svg` + `dataUri`
`provchart_explain`	short notes (no API call)

Paint doesn't need a client chart runtime. The optional provchart-runtime only adds hover/tooltips on HTML charts, nothing required for the chart to just render.

Claude Desktop

{
  "mcpServers": {
    "provchart": {
      "command": "npx",
      "args": ["-y", "provchart-mcp"],
      "env": {
        "PROVCHART_API_KEY": "pc_live_xxxxxxxx"
      }
    }
  }
}

Key from chart.devtem.org/dashboard.

Prompt that works

Monthly signups: Jan 120, Feb 450, Mar 3200, Apr 8900. SVG for the README.

Values can be real numbers, not squeezed onto a 0–100 scale. Optional min / max if you want a fixed axis instead of auto-scaling.

After the tool returns

HTML: inject css into a <style> tag, html into a container.

SVG: write it to a file and use ![alt](./charts/name.svg) in Markdown. Better than a huge data URI sitting in your README source.

Related automation

If you want charts without chatting to an agent for each one:

provchart-readme-action — JSON config → SVG in CI
provchart-repo-stats — stars / languages → SVG for the README, pulled straight from GitHub's API

Site: chart.devtem.org · Docs: chart.devtem.org/docs

Automated GitHub repo stats as SVG in the README

FSCSS — Sun, 30 Aug 2026 16:51:53 +0000

Most README “stats” badges are either fixed images or another third-party widget. I wanted something simpler: read the repo from GitHub’s API, turn the numbers into SVG files in the repo, embed them like any image.

That’s what ProvChart Repo Stats does.

What it writes

File	Content	Default chart
`docs/charts/repo-overview.svg`	Stars, forks, watchers, open issues	area (real counts)
`docs/charts/languages.svg`	Language share	hbar

No hand-maintained chart JSON for those two.

Setup

Add a repo secret PROVCHART_API_KEY (key from chart.devtem.org/dashboard).
Workflow:

name: Repo stats charts

on:
  schedule:
    - cron: "0 8 * * 0"
  workflow_dispatch:

permissions:
  contents: write

jobs:
  charts:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: fscss-ttr/provchart-repo-stats@v1.3
        with:
          api-key: ${{ secrets.PROVCHART_API_KEY }}
        env:
          PROVCHART_API_KEY: ${{ secrets.PROVCHART_API_KEY }}

      - uses: stefanzweifel/git-auto-commit-action@v5
        with:
          commit_message: "chore: update repo stats charts"
          file_pattern: "docs/charts/*.svg"

README:

![Overview](./docs/charts/repo-overview.svg)
![Languages](./docs/charts/languages.svg)

Run the workflow once (or wait for the schedule). The SVGs commit back; the README stays normal Markdown.

Defaults worth knowing

Overview uses real counts (not forced to 0–100).
Languages use share %.
You can switch types (overview-type, languages-type) if you prefer bars.

Charts are generated with ProvChart (generate-svg). Related: provchart-readme-action if you already have a .provchart/charts.json and want fixed sample charts instead of live repo metrics.

Feedback and issues: github.com/fscss-ttr/provchart-repo-stats.

Keep README charts in sync with a small GitHub Action

FSCSS tutorial — Fri, 28 Aug 2026 13:32:25 +0000

I got tired of updating chart screenshots in READMEs by hand.

Either the numbers were stale, or I’d regenerate an image, commit it, and forget the next week. For docs and GitHub READMEs I don’t need a full chart library on the page — I need a vector file that still looks sharp.

So I wired ProvChart’s SVG API into a GitHub Action.

What it does

You describe charts in .provchart/charts.json
On schedule or workflow_dispatch, the Action calls the API
It writes .svg files into the repo (e.g. docs/charts/)
A commit step pushes them if anything changed

README stays simple:

![API traffic](./docs/charts/demo.svg)

No Chart.js in the README. No screenshot pipeline.

Minimal setup

Secret: PROVCHART_API_KEY (from the ProvChart dashboard)

Config (array of payloads):

[
  {
    "file": "demo.svg",
    "type": "area",
    "theme": "midnight",
    "width": 640,
    "height": 320,
    "axisX": ["Mon", "Tue", "Wed", "Thu", "Fri", "Sat", "Sun"],
    "series": [
      {
        "name": "Requests",
        "color": "#8b7bff",
        "points": [20, 85, 40, 60, 10, 40, 95]
      }
    ]
  }
]

Workflow sketch:

- uses: fscss-ttr/provchart-readme-action@v1.0.4
  with:
    api-key: ${{ secrets.PROVCHART_API_KEY }}
    config: .provchart/charts.json
    output-dir: docs/charts

Then auto-commit the docs/charts/*.svg files if you want.

Why this shape

SVG fits Markdown and docs better than a heavy client chart stack
CI owns refresh; the README only references files
Same JSON model as the rest of ProvChart (line, area, bar, gauge, …)

Gauges at about 220×220 work well in a README without taking over the page.

Try without starting from zero

Sample repo (fork → add the secret → run the workflow):

github.com/Figsh/provchart-charts

Action:

github.com/fscss-ttr/provchart-readme-action

Not a replacement for interactive dashboards. Just a practical way to keep docs charts honest without babysitting PNGs.

fscss-ttr / provchart-readme-action

CI generates SVG charts and commits them for README/docs

ProvChart README Action

Generate vector SVG charts with the ProvChart API inside GitHub Actions, then commit them for live README and docs embeds.

No Chart.js. No screenshot bots. Pure SVG from JSON.

Action	`fscss-ttr/provchart-readme-action`
Sample repo (fork & test)	Figsh/provchart-charts
API	chart.devtem.org
License	MIT

Try in 2 minutes (recommended)

Fork github.com/Figsh/provchart-charts
Add a repository secret: PROVCHART_API_KEY (Dashboard → Developer API)
Actions → run Test ProvChart Action (workflow_dispatch)
SVGs land under docs/charts/ and are committed automatically

That repo already has .provchart/charts.json, the workflow, and README embeds.

Quick start (your own repo)

1. API key secret

Settings → Secrets and variables → Actions → New repository secret

Name	Value
`PROVCHART_API_KEY`	Your ProvChart API key

2. Config — `.provchart/charts.json`

[
  {
    "file": "demo.svg"
    "type": "area",
    "theme": "midnight",
    "width": 640,
    "height": 320,
    "axisX": [

…

View on GitHub

How to ship interactive charts and still aim for 100 performance

FSCSS — Wed, 26 Aug 2026 11:57:55 +0000

Interactive charts and a perfect Lighthouse run often feel incompatible. The usual path is a 50–150 KB chart library, hydration, and a blank box until JavaScript finishes. You can still offer real visuals and light interaction without paying that tax on every page load.

This article is about a paint-first pipeline: compile data to HTML/CSS, let the browser draw on first paint, then add interaction as progressive enhancement.

The real performance problem

Core Web Vitals care about what blocks the main thread and what delays useful pixels.

Cost	Typical JS chart stack	Paint-first CSS charts
Download / parse	Chart library + adapters	No chart library for paint
First paint	Often after JS runs	Chart HTML/CSS in the first response
SEO / first crawl	Depends on hydration	Markup present immediately
Interaction	Built into the library	Optional small runtime

“100 performance” is never a guarantee—fonts, images, and third parties still matter—but removing chart-runtime JS from the critical path is one of the highest-leverage wins on dashboard-style pages.

Pipeline: compile → paint → enhance

1. Compile

Send JSON to a generator (build step or API). Example with ProvChart:

const res = await fetch("https://provchart-api.devtem.org/api/v1/generate", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    "X-API-Key": process.env.PROVCHART_API_KEY,
  },
  body: JSON.stringify({
    type: "area",
    series: [
      { name: "Traffic", color: "#4fd8c4", points: [30, 45, 40, 60, 55, 70, 65] },
      { name: "Signups", color: "#f0a860", points: [8, 12, 11, 18, 16, 22, 20] },
    ],
    axisX: ["Mon", "Tue", "Wed", "Thu", "Fri", "Sat", "Sun"],
  }),
});

const { success, html, css, error } = await res.json();
if (!success) throw new Error(error);

You get scoped HTML + CSS (custom properties, clip-path, bars, gauges)—not a client chart framework.

2. Paint

Inject on the server or at the start of the page:

document.head.insertAdjacentHTML("beforeend", `<style>${css}</style>`);
document.getElementById("chart").innerHTML = html;

On first paint the chart is already geometry in CSS. No new Chart(ctx, …).

3. Enhance (optional)

Interaction does not have to ride in the same bundle as rendering.

ProvChart Runtime is a separate MIT script: tooltips, scroll reveal, legend focus. Charts work without it.

<script>
  window.ProvChartRuntimeConfig = {
    tooltips: true,
    perPointTooltips: true,
    observe: true,
    excludeSvg: true,
  };
</script>
<script src="https://cdn.jsdelivr.net/npm/provchart-runtime@1.2.0/dist/provchart-runtime.min.js" defer></script>

Pattern: render is free of chart-library JS; UX is progressive.

What “interactive” can mean without a heavy library

Need	Lightweight approach
Hover values	Runtime tooltips / CSS hits
Legend focus	Dim other series on legend hover
Live data	Rewrite CSS variables or re-call generate
README / docs	`generate-svg` → commit `.svg` (no client runtime)
Full brush/zoom/analytics	Reserve a JS library for that route only

Most marketing pages, pricing metrics, and ops KPI strips need the first column—not a full analytics suite.

Checklist toward a top performance score

No chart library on the critical path — generate HTML/CSS ahead of time or via API; inline or ship only scoped CSS.
Defer enhancement — defer / type="module" for runtime; charts remain visible if it fails.
Respect prefers-reduced-motion — skip transform theatre when users ask.
Keep images honest — LCP is often a hero image, not the chart; optimize that separately.
Don’t block on fonts — font-display: swap for display type.
Split the product — paint-first charts on public pages; heavy JS charts only behind “Analytics” where interaction earns the KB.
Accessibility — short text summary + optional table (accessible charts).

Static sites and agents

SSG: generate charts at build time; commit HTML/CSS or call the API in CI.
README: prefer SVG file embeds over giant data URIs (Markdown guide).
Agents: stable JSON in → markup out is easy for ChatGPT/Claude tool calls—no browser chart API required.

When you should still use a JS chart library

Brushing, zooming, streaming ticks
Dozens of coordinated views
Exotic types your CSS engine doesn’t cover

Use them deliberately, on routes that justify the cost—not as the default for every sparkline.

Quick start

Build or API-generate a chart → inject html + css.
Confirm the chart shows with JS disabled (enhancement only).
Add runtime only if you want tooltips/motion.
Re-run Lighthouse on mobile; watch JS execution time and LCP.

Docs: chart.devtem.org/docs

Gallery: chart.devtem.org/gallery

Runtime: github.com/fscss-ttr/provchart-runtime

Maximize the visual by maximizing what the browser already paints. Compile data to CSS, ship interaction as an optional layer, and keep heavy chart runtimes off pages that don’t need them. That’s how interactive-looking charts stay compatible with serious performance budgets.

Pure CSS Charts + Drop-in Interactivity: ProvChart API & Runtime

FSCSS tutorial — Tue, 25 Aug 2026 16:34:50 +0000

Most chart libraries tax every page: 40–150 KB of JS, hydration delay, and markup crawlers never see. ProvChart takes another path—data becomes HTML and CSS (custom properties + clip-path). ProvChart Runtime is an optional script that adds tooltips, motion, and legend focus without changing how charts are generated.

This post walks through a minimal setup: generate an area chart from the API, inject it, and let the runtime enhance it.

What you get

Layer	Role
ProvChart API	`POST /api/v1/generate` → `{ html, css }` — zero chart-library runtime on the page
ProvChart Runtime	Scans `[data-provchart]`, adds hover tooltips, scroll reveal, legend dimming
SVG API (optional)	`POST /api/v1/generate-svg` for README/docs — runtime skips pure SVG by design

Repo / install:

github.com/fscss-ttr/provchart-runtime
npm i provchart-runtime
CDN: jsDelivr or unpkg

Product: chart.devtem.org

1. Get an API key

Sign in at chart.devtem.org
Open Dashboard → Developer API
Create a key

Signed-up free accounts get a monthly test quota. HTML and SVG generations share the same pool.

2. Minimal page

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8" />
  <meta name="viewport" content="width=device-width, initial-scale=1.0" />
  <title>ProvChart + Runtime</title>
  <style>
    body {
      margin: 0;
      min-height: 100vh;
      display: flex;
      align-items: center;
      justify-content: center;
      background: #0c0a16;
      font-family: system-ui, sans-serif;
    }
    #chart { width: min(640px, 92vw); }
    .err { color: #ff5e7d; font-size: 14px; padding: 16px; }
  </style>

  <script>
    window.ProvChartRuntimeConfig = {
      animation: true,
      revealOnScroll: true,
      tooltips: true,
      perPointTooltips: true,
      observe: true,
      selector: '[data-provchart]',
      excludeSvg: true,
    };
  </script>
  <script src="https://cdn.jsdelivr.net/npm/provchart-runtime@1.0.0/dist/provchart-runtime.min.js"></script>
</head>
<body>
  <div id="chart"></div>

  <script type="module">
    const API = 'https://provchart-api.devtem.org/api/v1/generate';
    const API_KEY = 'YOUR_API_KEY';

    const payload = {
      type: 'area',
      series: [
        { name: 'Traffic', color: '#4fd8c4', points: [30, 45, 40, 60, 55, 70, 65] },
        { name: 'Signups', color: '#f0a860', points: [8, 12, 11, 18, 16, 22, 20] },
      ],
      axisX: ['Mon', 'Tue', 'Wed', 'Thu', 'Fri', 'Sat', 'Sun'],
    };

    const mount = document.getElementById('chart');

    try {
      const res = await fetch(API, {
        method: 'POST',
        headers: {
          'Content-Type': 'application/json',
          'X-API-Key': API_KEY,
        },
        body: JSON.stringify(payload),
      });
      const data = await res.json();
      if (!data.success) throw new Error(data.error || 'Generate failed');

      let style = document.getElementById('provchart-style');
      if (!style) {
        style = document.createElement('style');
        style.id = 'provchart-style';
        document.head.appendChild(style);
      }
      style.textContent = data.css || '';
      mount.innerHTML = data.html || '';

      // Optional: only if your build exposes it
      // window.ProvChartRuntime?.scan?.();
    } catch (err) {
      mount.innerHTML = `<p class="err">${err.message}</p>`;
    }
  </script>
</body>
</html>

Replace YOUR_API_KEY. After load you should see a two-series area chart; hover legend/points if the runtime attached correctly.

3. How the runtime finds charts

Generated roots look like:

<div class="pc-chart-…" data-provchart="area">…</div>

The runtime:

Queries [data-provchart]
Skips pure SVG embeds when excludeSvg: true
Uses a MutationObserver so charts injected via fetch still get enhanced
Reads series points from CSS variables like --pc-{id}-s1-p1 for per-point tooltips

You don’t call into ProvChart’s core from the client for paint—the browser already painted CSS.

4. Config worth knowing

window.ProvChartRuntimeConfig = {
  animation: true,
  revealOnScroll: true,
  tooltips: true,
  perPointTooltips: true,
  countUp: true,      // gauge / stat numbers
  observe: true,      // watch DOM for new charts
  excludeSvg: true,   // leave README SVGs alone
};

Define this before the runtime script tag.

5. HTML/CSS vs SVG

Use case	Endpoint	Runtime
App UI, dashboard, marketing page	`/api/v1/generate`	Yes
GitHub README, static docs asset	`/api/v1/generate-svg`	No (commit `.svg` or data URI)

Same payload shape (type, series, axisX); different output.

6. Why this split matters

Performance: no Chart.js-sized dependency to parse before first paint
SEO: chart structure is in HTML/CSS on first response
Progressive enhancement: runtime is optional; charts work without it
Docs vs apps: SVG for Markdown hosts; HTML/CSS + runtime for product UI

Links

generate charts as HTML and CSS, ship them with almost no client chart code, and add interactivity only when you want it—with a single script tag

Embed Charts in Markdown Without Chart.js: SVG, Data URIs, and What Actually Works

FSCSS — Mon, 24 Aug 2026 11:08:20 +0000

Markdown is great until you want a real chart in a README or docs site. Most people reach for a screenshot, a hosted PNG, or a heavy client library. ProvChart takes another path: POST /api/v1/generate-svg returns a self-contained SVG (and optional data URI) from your data—no js on the page, no image CDN required.

This article covers what different Markdown platforms allow, practical embed patterns, and when pure SVG is the better default.

The idea

Send series data to ProvChart’s SVG endpoint.
Get back:
- svg — full <svg xmlns="...">...</svg> string
- dataUri — data:image/svg+xml;base64,...
Embed with whatever your platform supports.

Platform reality: not every Markdown engine is equal

Approach	GitHub README	Many static docs	Personal / controlled MD	Notes
Data URI `![](data:image/svg+xml;...)`	Often fragile	Sometimes OK	Often OK	Long base64 can break or get sanitized
`<img src="data:...">`	Limited	Varies	Often OK	Same length / sanitize issues
File `![](./chart.svg)`	✅ Reliable	✅ Reliable	✅ Best default	Commit the SVG; no key in the repo
Inline `<svg>`	❌ Usually stripped	Sometimes	✅ If HTML allowed	Great for MDX / some SSGs
Raster PNG/WebP	✅	✅	✅	Use only if the host blocks SVG

Takeaway: Prefer a committed .svg file for GitHub and public docs. Use data URIs for quick demos. Use inline SVG only where the engine allows raw HTML (MDX, some wikis, your own site).

Pattern 1 — Generate SVG (API)

curl -s -X POST "https://provchart-api.devtem.org/api/v1/generate-svg" \
  -H "Content-Type: application/json" \
  -H "X-API-Key: YOUR_API_KEY" \
  -d '{
    "type": "line",
    "series": [
      { "name": "Stars", "color": "#8b7bff", "points": [12, 18, 25, 40, 55] }
    ],
    "axisX": ["Jan", "Feb", "Mar", "Apr", "May"],
    "width": 640,
    "height": 280
  }'

Response shape:

{
  "success": true,
  "svg": "<svg xmlns=\"http://www.w3.org/2000/svg\" ...>...</svg>",
  "dataUri": "data:image/svg+xml;base64,..."
}

Keep the key in CI secrets.

Pattern 2 — Embed options

A. Image from file (recommended for README)

![Stars over time](./docs/charts/stars.svg)

Save the svg field from the API into that path and commit it.

B. Data URI (quick, not always portable)

![Stars over time](data:image/svg+xml;base64,AAAA...)

If the preview is blank, the host likely truncated or blocked the URI—switch to a file.

C. Inline SVG (when HTML is allowed)

<!-- MDX / some static generators -->
<div>
  <!-- paste the svg string from the API -->
</div>

GitHub README will generally not render arbitrary inline SVG.

D. Raster only if you must

If a platform blocks SVG entirely, convert once in your pipeline (e.g. local tool) and commit PNG. That’s a fallback—not the default for your docs site, where SVG is usually better.

Advantages of the SVG path

No chart runtime in the doc UI — readers don’t download Chart.js to see a trend.
No third-party image host — nothing uploaded to a random CDN for a badge.
Sharp at any zoom — useful for docs and retina displays.
Same data model as HTML charts — type, series, axisX match ProvChart’s generate API.
CI-friendly — regenerate docs/charts/*.svg when metrics change; commit the artifact.
Fits the “pipeline” story — compile data → paint geometry; for Markdown the paint target is SVG instead of CSS-in-page.

When pure SVG is the better choice

Personal knowledge bases, Notion-export-style vaults, and static doc sites you control
GitHub/GitLab asset charts (versioned next to the repo)
Design systems / architecture READMEs that should stay dependency-light
Agent or cron jobs that refresh charts without opening a browser

Use HTML + CSS (/api/v1/generate) when the chart lives inside a web app where theme tokens and layout already use CSS.

Minimal Node helper (write a file)

import fs from "node:fs";

const res = await fetch("https://provchart-api.devtem.org/api/v1/generate-svg", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    "X-API-Key": process.env.PROVCHART_API_KEY,
  },
  body: JSON.stringify({
    type: "area",
    series: [{ name: "Views", color: "#4fd8c4", points: [10, 25, 40, 55, 48] }],
    axisX: ["Mon", "Tue", "Wed", "Thu", "Fri"],
    width: 640,
    height: 240,
  }),
});

const data = await res.json();
if (!data.success) throw new Error(data.error);
fs.writeFileSync("docs/charts/views.svg", data.svg);

Point Markdown at ./docs/charts/views.svg.

Troubleshooting

Symptom	Likely cause	Fix
Broken image in README	Data URI too long / blocked	Commit `.svg` + relative path
401	Bad or revoked key	New key in Dashboard → Developer API
429	Monthly limit	Upgrade plan or wait for reset
Empty graphic	Bad payload	Check `series[].points` and `axisX`

Links

SVG API: ProvChart docs – generate-svg
Guide: Charts in Markdown & docs
Pricing (quota): chart.devtem.org/pricing

Markdown support for data: URIs is inconsistent. For public README and most docs, generate SVG - save file - ![](./chart.svg). Use data URIs for experiments; use inline SVG only where your engine allows HTML. That’s how you get charts in docs.

Email Charts with the ProvChart API

FSCSS — Sun, 23 Aug 2026 10:41:23 +0000

Most chart libraries assume a browser that runs JavaScript. Email clients don't give you that. If you want a chart in a weekly digest, you need something that renders without a script tag, or a step that turns a chart into an image before it ever reaches an inbox.

That's the problem ProvChart's API is built for. It returns HTML and CSS, generated server-side, and you decide from there whether to rasterize it into a PNG or embed a tightly controlled snippet. This post walks through the flow, the chart types that actually work in a digest, and a handful of practical tips for running this in production.

Why email is different

The inbox never needs to see your API key or your chart library. It only needs a static image and a link back to the live dashboard. Everything else, the data pull, the payload mapping, the API call, happens on your server or in a worker, before the send.

The flow

Pull analytics for the period, from your API, warehouse, or database
Map the rows into a ProvChart payload (type, series, axisX, theme)
POST /api/v1/generate with your API key
Turn the returned html and css into a PNG (or store the snippet)
Embed the result in your email template with a CTA back to the dashboard

Mapping analytics to a payload

Keep a single mapper function so every report type shares the same shape:

function analyticsToPayload(report) {
  return {
    type: "line",
    series: [
      {
        name: "Revenue",
        color: "#8b7bff",
        points: report.revenueByDay.map(d => d.value)
      },
      {
        name: "Orders",
        color: "#4fd8c4",
        points: report.ordersByDay.map(d => d.value)
      }
    ],
    axisX: report.revenueByDay.map(d => d.label),
    theme: {
      bg: "#0c0a16",
      surface: "#1a1628",
      text: "#eae7f5",
      muted: "#837da0",
      grid: "#8b7bff",
      radius: "12px"
    }
  };
}

Swap the data source underneath it, but keep the function stable. Weekly, monthly, and alert emails all stay consistent this way.

Chart types that actually work in a digest

Use case	Type	Why
Trend over 7–30 days	`line` / `area`	Readable as a simple story
Channel or category mix	`bar`	Clear comparison
Goal or conversion	`gauge`	One number, high impact
Share of total	`stackedbar`	Good for mix breakdowns

Skip dense scatter plots or multi-combo charts in email. Save those for the product UI, where someone can actually zoom in and interact.

Ten things worth doing

Generate server-side. The send job or worker owns the API key, the payload, and the output. Never call the API from the client.
Prefer images for email clients. The reliable path is: analytics → API → html/css → headless render (Playwright or Puppeteer) → PNG → CDN → <img> in the template. This works across Gmail, Outlook, and Apple Mail.
Design for one glance. Each chart should answer one question: did revenue rise, which channel led. Cap it at one or two series and 7–14 data points. Put the headline number in the subject line or preheader.
Cache by payload hash. Identical type, series, labels, and theme should produce identical output. Cache the html/css or the PNG so repeat sends don't burn quota.
Check usage before bulk sends. Hit GET /api/v1/usage first. If remaining is low, drop the optional charts or fall back to number-only blocks rather than hitting MONTHLY_LIMIT_REACHED mid-campaign.
Theme for email, not the admin UI. Use higher contrast and a background that matches your template. A dedicated theme object for digests versus in-app charts goes a long way.
Always add a CTA. A simple "Full dashboard →" link under the chart. The email is the snapshot; the app is where people explore.
Keep one layout per digest type. Hero metric, one trend chart, one breakdown, a few bullets, then the CTA. Change the data, not the structure.
Validate before you generate. Empty series, non-numeric points, or oversized arrays waste generations. Enforce max points and required fields in the mapper itself.
Proxy the key. Production frontends shouldn't hold the secret key at all. Route browser requests through your own backend before they reach ProvChart.

A minimal server-side example

const payload = analyticsToPayload(weeklyReport);

const res = await fetch("https://provchart-api.devtem.org/api/v1/generate", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    "X-API-Key": process.env.PROVCHART_API_KEY
  },
  body: JSON.stringify(payload)
});

const data = await res.json();
if (!data.success) throw new Error(data.error);

// Option A: rasterize data.html + data.css into a PNG, upload it, then <img src="...">
// Option B: store the snippet for a web version of the same report

Do / Don't

Generate server-side
Map analytics to a fixed payload shape
Cache by hash
Prefer line, bar, or gauge charts
Link back to the live dashboard

Don't

Call the API from the inbox
Build ad-hoc JSON for every send
Regenerate identical charts
Pack five dense series into a digest
Expect full interactivity in email

Next steps

Introduction to ProvChart — Charts Without the JavaScript Tax

FSCSS — Sat, 22 Aug 2026 08:28:32 +0000

Introduction to ProvChart

Most charting libraries ask you to ship 40–150 kb of JavaScript, wait for hydration, and hope crawlers eventually see the chart.

ProvChart takes a different path.

It turns your data into CSS custom properties. The browser paints the chart with native CSS (clip-path, gradients, and a few carefully chosen rules). The result is a chart that:

Loads with the first paint
Ships zero chart library to the page
Is fully visible to search engines on the first crawl
Can still be updated by changing CSS variables

No canvas. No SVG charting runtime. No “wait for JS.”

The idea in one sentence

Data → CSS variables → browser paints the shape.

You (or the API) compile points into variables like --p1, --p2, ….

A pure CSS structure uses those variables to draw lines, areas, bars, or gauges.

After that, the page doesn’t need a charting library at all.

What you get

Feature	Detail
Output	Self-contained HTML + CSS
Runtime on the page	None for the chart itself
Types	Line, area, bar, stacked bar, horizontal bar, scatter, combo, gauge
Themes	Dark, light, midnight, or fully custom
SEO	Chart markup is in the first HTML response
Updates	Change CSS variables (or regenerate) — no virtual DOM chart layer

There is also a Developer API: send JSON, get back { html, css }, inject into any page or pipeline.

Who it’s for

Teams that care about LCP, TTI, and bundle size
Marketing and docs sites that need crawlable charts
Static or mostly-static pages that still need real data viz
Backends that want to generate charts for emails, reports, or static builds without shipping a client-side chart library

If you need heavy interaction, streaming of thousands of points, or complex JS-driven animations, a traditional library may still fit better. ProvChart optimizes for performance, simplicity, and SEO.

Quick taste (API)

const res = await fetch("https://provchart-api.devtem.org/api/v1/generate", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    "X-API-Key": "YOUR_API_KEY"
  },
  body: JSON.stringify({
    type: "line",
    series: [
      { name: "Revenue", color: "#8b7bff", points: [20, 35, 48, 66] },
      { name: "Users", color: "#4fd8c4", points: [12, 28, 41, 55] }
    ],
    axisX: ["Jan", "Feb", "Mar", "Apr"]
  })
});

const data = await res.json();
// data.html + data.css → inject into the page

Free accounts get a few test generations so you can try the full flow.

Pro and Business unlock higher monthly limits for production use.

Open source core + hosted product

Rendering core: st-core.fscss (MIT) — pure CSS chart primitives for the FSCSS ecosystem
Hosted product: ProvChart — visual builder, dashboard, Developer API, billing (by DevTemple)

You can use the open-source core on its own, or the hosted API when you want keys, limits, and multi-series generation without maintaining the engine yourself.

Try it

Link	What
chart.devtem.org	Product home
Get started	Free visual builder (no signup for single-series)
Docs	Core + Developer API
Pricing	Free / Pro / Business

What’s next from this org

We’ll publish short, practical posts on:

Building a small chart generator with the API
Using ProvChart in email digests (server-side → image/snapshot)
Performance and SEO notes vs typical JS chart stacks
Themes, multi-series patterns, and real dashboard layouts

If you care about charts that stay fast and crawlable, you’re in the right place.

ProvChart — charts without the JavaScript tax.

chart.devtem.org

DEV Community: ProvChart

Building a Lightweight Portfolio Dashboard with ProvChart & st-core Tokens

The problem with typical chart libraries

Stack overview

How ProvChart is wired in

1. Server-side proxy (key stays private)

2. Client payload (real numbers, not 0–100)

3. Inject HTML + CSS

Data shape: 9 points, clear narrative

Dashboard features in the template

Getting started

Why this approach works

Repo & next steps

Generate pure CSS charts from Claude (or any MCP client)

Package

Tools

Claude Desktop

Prompt that works

After the tool returns

Related automation

Automated GitHub repo stats as SVG in the README

What it writes

Setup

Defaults worth knowing

Keep README charts in sync with a small GitHub Action

What it does

Minimal setup

Why this shape

Try without starting from zero

fscss-ttr / provchart-readme-action

CI generates SVG charts and commits them for README/docs

ProvChart README Action

Try in 2 minutes (recommended)

Quick start (your own repo)

1. API key secret

2. Config — .provchart/charts.json

How to ship interactive charts and still aim for 100 performance

The real performance problem

Pipeline: compile → paint → enhance

1. Compile

2. Paint

3. Enhance (optional)

What “interactive” can mean without a heavy library

Checklist toward a top performance score

Static sites and agents

When you should still use a JS chart library

Quick start

Pure CSS Charts + Drop-in Interactivity: ProvChart API & Runtime

What you get

1. Get an API key

2. Minimal page

3. How the runtime finds charts

4. Config worth knowing

5. HTML/CSS vs SVG

6. Why this split matters

Links

Embed Charts in Markdown Without Chart.js: SVG, Data URIs, and What Actually Works

The idea

Platform reality: not every Markdown engine is equal

Pattern 1 — Generate SVG (API)

Pattern 2 — Embed options

A. Image from file (recommended for README)

B. Data URI (quick, not always portable)

C. Inline SVG (when HTML is allowed)

D. Raster only if you must

Advantages of the SVG path

When pure SVG is the better choice

Minimal Node helper (write a file)

Troubleshooting

Links

Email Charts with the ProvChart API

Why email is different

The flow

Mapping analytics to a payload

Chart types that actually work in a digest

Ten things worth doing

A minimal server-side example

Do / Don't

Next steps

Introduction to ProvChart — Charts Without the JavaScript Tax

2. Config — `.provchart/charts.json`