Why Valid SVG Is Not Good SVG: Improving Gemini Nano for Browser-Local Vector Design

A parser can tell me whether an SVG is valid and safe. It cannot tell me whether the design is good.

That distinction has become one of the most interesting problems in Timeline Studio, the open-source, local-first video editor I am building for the browser.

Timeline Studio can generate editable vector graphics with Gemini Nano through Chrome’s built-in Prompt API. The whole workflow stays in the browser: the request is detected and translated locally, the model generates SVG, and the result is sanitized before it is added to the user’s asset library.

The pipeline works. But “works” is not the same as “produces a useful design.”

The current browser-local pipeline

The generation flow is intentionally small:

1. Detect the actual language of the request.
2. Translate non-English input to English in the browser.
3. Ask Gemini Nano for one standard SVG document.
4. Extract the first complete SVG from Markdown fences or surrounding prose.
5. Sanitize elements, attributes, links, scripts, and external resources.
6. Normalize the result into a 1200 × 1200 viewBox.
7. Add the vector to My Assets without inserting it into the timeline automatically.

The shipped code is roughly this simple:

const raw = await session.prompt(buildVectorDesignPrompt(englishRequest));
const vectorXml = extractVectorXml(raw);
const vectorBody = sanitizeGeneratedVectorXml(vectorXml, scope);

The parser is deliberately tolerant. Gemini Nano may return a clean SVG, wrap it in a Markdown code fence, add a sentence before it, or use an older custom wrapper. The extractor handles those cases before the sanitizer applies the real safety boundary.

What validation catches

The current validation layer is good at rejecting structural and security problems:

• missing or malformed SVG markup
• scripts and event handlers
• unsafe or unsupported elements
• external URLs and embedded remote content
• attributes that do not belong in an editable vector asset
• output that cannot be normalized into the editor’s coordinate system

This is necessary. Generated markup should never be trusted just because it came from a local model.

But a safe SVG can still be a bad SVG.

What validation misses

Visual quality failures are much harder to express as pass or fail:

• the artwork is clipped even though the viewBox is valid
• the composition technically matches the request but feels generic
• a supposedly transparent asset contains a full-canvas background rectangle
• the illustration is almost empty or uses too few meaningful shapes
• dozens of tiny shapes make the vector difficult to edit
• groups exist, but their IDs and hierarchy are not useful
• typography, spacing, or contrast makes the asset unusable in a video
• translation preserves the words but loses the design intent

None of these necessarily produces invalid XML. A sanitizer can accept all of them.

This is the part I want to improve next.

A reproducible SVG quality benchmark

Before changing prompts or adding repair logic, I want a small benchmark that makes regressions visible.

The first version should contain at least 24 prompts across:

• icons and simple symbols
• lower thirds and title graphics
• charts and infographic elements
• callouts, labels, and badges
• frames and mask-like compositions
• abstract motion-graphics assets
• at least four non-English requests

Each result can be reviewed with a compact human rubric:

1. Request fidelity — does the image represent what was asked for?
2. Composition — are spacing, balance, and hierarchy usable?
3. Polish — does it look intentional rather than merely generated?
4. Editability — are groups and shapes structured for later editing?
5. Safety and transparency — does it stay within the editor’s SVG rules?

The goal is not to invent one magical quality score. It is to create a repeatable set of prompts and examples so that a prompt change can be compared with the previous behavior.

Deterministic checks before another model call

Some visual failures can be approximated cheaply without running a second inference:

• empty or nearly empty visible bounds
• shapes extending far outside the viewBox
• a large opaque element covering almost the entire canvas
• extreme coordinate values
• excessive shape or filter complexity
• duplicate, missing, or unhelpful group IDs
• content clustered into a tiny fraction of the canvas

These checks will never replace visual review, but they can produce a machine-readable report. More importantly, they can explain a failure instead of returning a vague “generation failed” message.

One bounded local repair pass

The next experiment is a single optional repair attempt. This is a proposal, not a shipped feature yet:

const report = analyzeSvgQuality(vectorXml);

if (report.repairable && experiments.svgRepair) {
  const repaired = await repairOnce({
    request: englishRequest,
    svg: vectorXml,
    report,
  });

  return sanitizeGeneratedVectorXml(
    extractVectorXml(repaired),
    scope,
  );
}

The repair prompt would receive the original English request, the generated SVG, and a short list of deterministic warnings. It would keep the same element and safety constraints and would run at most once.

Why only once?

Because an unlimited generate-check-repair loop is unpredictable on a user’s laptop. Browser-local software has to respect memory, battery, model latency, cancellation, and weaker hardware. A bounded repair step is easier to understand, test, and disable.

The repaired result must also pass through the exact same extractor and sanitizer. Repair is not a security exception.

Why the local-first constraint matters

Using a hosted vision model could make evaluation and repair easier, but it would change the product boundary. Timeline Studio is exploring what a capable editor can do without uploading project media or design prompts to a backend.

That creates useful engineering constraints:

• no server-side SVG cleanup service
• no hidden cloud fallback
• no unbounded retries
• clear errors when browser AI or local translation is unavailable
• generated assets remain editable and are never silently placed on the timeline

The constraint is not just about privacy. It forces the quality system to be understandable and reproducible.

I am looking for contributors

I opened two research issues for this work:

• Research spike: improve browser-local AI SVG generation quality
• Prototype an SVG quality checker and local repair pass for Gemini Nano

These are good contributions for someone interested in browser AI, SVG internals, evaluation, prompt design, or developer tooling. You do not need to solve the entire system. A useful prompt set, a measurable static check, a failure taxonomy, or a small repair prototype would already move the project forward.

You can try Timeline Studio in the browser or explore the source on GitHub.

If you have worked on generated SVG quality before, I would especially like to hear how you separate “valid output” from “useful design.”