DEV Community: hw lu

How I Built a Browser-Only Bubble Text Generator with SVG and Canvas

hw lu — Mon, 17 Aug 2026 01:30:13 +0000

Visual text generators look simple from the outside: type a phrase, choose a style, and download an image.

The implementation gets more interesting when the whole pipeline has to stay in the browser. The preview must match the exported PNG, fonts must render consistently across devices, transparent margins should be cropped, and changing a slider should not make the layout jump.

I recently built a small browser-based text-art generator to explore that problem. This post explains the architecture and the details that took the most work.

What I wanted the tool to do

The product requirements were intentionally narrow:

Accept a short phrase, including line breaks and mixed case
Offer three visibly different font shapes
Apply eight finishes such as glossy, sugar, holographic, chrome, neon, and sticker
Let the user change the font size and color
Preview changes immediately
Export a watermark-free PNG
Keep the phrase and rendering work inside the browser
Avoid accounts, uploads, and a server-side image API

The last requirement shaped almost every technical decision.

The rendering pipeline

The editor is a Client Component in a Next.js App Router project. React owns the controls, but the artwork itself is created by a pure TypeScript function.

The pipeline looks like this:

React controls
  -> SVG string
  -> SVG Blob
  -> HTML Image
  -> Canvas raster
  -> alpha-bound scan
  -> cropped PNG Blob

Keeping SVG generation in a pure function made it easier to test every combination without a browser. The browser-specific work is limited to font loading, text measurement, preview rasterization, and downloading.

Why SVG was a good fit

SVG gives text effects a useful middle ground between plain CSS and a full graphics engine.

Each finish is built from three text layers:

An outer stroke and shadow
The main gradient-filled text
A thin highlight shifted slightly upward and left

A simplified version looks like this:

<g text-anchor="middle" dominant-baseline="middle">
  <text
    fill="url(#gummyFill)"
    stroke="#8a174e"
    paint-order="stroke fill"
    filter="url(#softShadow)">
    HELLO
  </text>

  <text
    fill="url(#gummyFill)"
    stroke="#ff4fa3"
    paint-order="stroke fill">
    HELLO
  </text>

  <text
    fill="none"
    stroke="#ffffff"
    transform="translate(-2 -4)">
    HELLO
  </text>
</g>

The styles share the same renderer. Only a finish profile changes the gradient definitions, texture filter, stroke policy, and outer filter.

That is important because it prevents style logic from being scattered across the codebase. Adding a new finish means defining one complete rendering profile rather than updating several conditionals.

Making fonts consistent across devices

Relying on system font stacks caused an early problem. A rounded font and a chunky font can look different on one desktop and collapse to similar fallback fonts on another device.

I fixed that by bundling the font files with the application.

When a user selects a shape, the browser:

Fetches the matching TTF file
Waits for the browser font to load
Converts the file to a data URL
Embeds it into the generated SVG with @font-face

That makes the SVG self-contained before it is rasterized. The preview and the downloaded PNG therefore use the same font data instead of depending on whatever fonts happen to be installed on the device.

Measuring text before sizing the canvas

Character count is not a reliable width measurement. A string full of W characters can be much wider than a string of i characters with the same length.

The renderer uses CanvasRenderingContext2D.measureText with the selected family, weight, style, size, and letter spacing. The widest line determines the SVG canvas width.

The canvas is then sized around the measured artwork:

const widestLine = Math.max(
  fontSize,
  ...lines.map((line) => measureLine(line, fontSize)),
)

const padding = Math.max(24, fontSize * 0.22)
const width = Math.round(widestLine + padding * 2)
const height = Math.round(
  lines.length * fontSize * 0.94 + padding * 2,
)

This avoids two opposite problems:

Long phrases getting clipped
Short phrases being exported inside a huge fixed square

It also means a larger font size produces a genuinely larger PNG instead of merely scaling the same fixed canvas.

Keeping the preview stable

A tightly sized export is useful, but a tightly sized live preview can be distracting. The preview frame would change width on every keystroke and every font-size adjustment.

I use two SVG renders from the same source options:

The preview SVG uses a frame sized for the maximum font size
The download SVG is sized tightly around the selected font size

The text effect is identical, but the preview has a stable visual frame. The exported file remains compact.

The preview raster is capped at a smaller resolution for responsiveness, while export can use a larger maximum side. Neither path upscales the artwork beyond its natural dimensions.

Auto-cropping the PNG

After loading the SVG into an Image element, the browser draws it onto a temporary canvas. For transparent exports, the code reads the alpha channel and finds the first and last nontransparent pixel on each axis.

A safe margin is added to those bounds so shadows and glow effects are not cut off. The selected rectangle is then copied to a second canvas and encoded as PNG.

This step is skipped when the user chooses a solid or gradient background, because the background intentionally fills the entire canvas.

The same rasterization function is used by both preview and download. Sharing that path prevents the common bug where the editor looks correct but the saved file has different spacing or clipping.

Small details that mattered

A few less obvious issues were worth handling explicitly.

SVG whitespace

Regular spaces can be collapsed or stripped when SVG text is rasterized. Replacing user-entered spaces with non-breaking spaces keeps single and repeated spaces visible.

Stale asynchronous previews

Rendering is asynchronous. If a user types quickly, an older render can finish after a newer one. Each effect cleanup marks its render inactive so stale results cannot replace the latest preview.

Object URL cleanup

Every generated preview creates an object URL. The previous URL is revoked when a new preview replaces it, and the current URL is revoked when the component unmounts.

Input limits

The editor accepts short display text rather than paragraphs. A small character limit keeps the interface focused and prevents extreme canvas dimensions.

The result

The finished tool is GummyType. It creates bubble, Y2K, and chrome-style word graphics, and everything described above runs locally in the browser.

The project reminded me that a small visual tool can still contain several interesting browser-engineering problems: font portability, SVG composition, accurate measurement, asynchronous rendering, raster export, and memory cleanup.

What I would add next

The current version deliberately keeps the workflow simple. Possible future improvements include:

More font shapes without making the control panel overwhelming
SVG export for users who need editable artwork
Reusable presets for common visual styles
Better keyboard controls and accessibility feedback
More export backgrounds and layout templates

For now, the most useful constraint has been keeping the tool focused: short text in, finished image out, with no server rendering step in between.

If you have built a browser-based image or SVG tool, I would be interested to hear which rendering edge cases caused the most trouble for you.

How to Create Charts from CSV Files Without Excel

hw lu — Tue, 09 Jun 2026 05:48:32 +0000

CSV files are everywhere: analytics exports, sales reports, product usage logs, survey results, finance data, and database dumps. But turning a CSV into a quick chart can still feel heavier than it should.

Most people open Excel or Google Sheets, clean the data, select a chart type, adjust the axes, export an image, and then paste it into a report or slide deck. That works, but it is not always the fastest path when you just need a simple line chart, bar chart, or scatter plot.

This post walks through a lightweight workflow for creating charts from CSV files without starting a full spreadsheet project.

When a spreadsheet is more than you need

Spreadsheets are great when you need formulas, pivot tables, collaboration, or manual editing. But for quick visualization, they can add friction:

You have to import the file correctly.
Numeric columns may be treated as text.
Dates may be parsed differently depending on locale.
Exporting a clean chart image takes extra steps.
The file may contain data you do not want to upload to a shared workspace.

If the task is just "show me how this CSV changes over time," a smaller workflow is often enough.

A simple CSV-to-chart workflow

The most reliable workflow is:

Start with a clean CSV file.
Pick the column for the X axis.
Pick one or more numeric columns for the Y axis.
Choose a chart type.
Export the chart as PNG or SVG.

That is enough for many common cases:

Monthly revenue by region
Product usage over time
Survey responses by category
Error counts per release
CSV exports from internal tools
Simple comparisons across numeric columns

For example, a file like this can become a line chart quickly:

month,visits,signups,paid_users
2026-01,1200,84,12
2026-02,1480,101,18
2026-03,1760,133,21
2026-04,1690,126,24

Use month as the X axis, then plot visits, signups, or paid_users as Y values.

Common issues to check before charting

If a CSV does not chart correctly, the problem is usually in the data shape rather than the chart tool.

1. Numbers are stored as text

Values like $1,200, 1,200 users, or ~1200 may not be treated as numbers. Remove symbols and units before charting.

2. There are extra header rows

CSV exports from reporting tools often include a title row, notes, or metadata before the actual header. The first row should usually be the column names.

3. Dates are inconsistent

Try to keep dates in a consistent format such as YYYY-MM-DD or YYYY-MM. This makes the X axis easier to read and sort.

4. The data is too aggregated or not aggregated enough

If you need "sales by region per month," make sure each row has a clear month and region, or aggregate the data first in a spreadsheet or script.

Tool options

There are several good ways to make charts from CSV data:

Google Sheets or Excel if you need editing, formulas, or pivot tables.
Python with pandas and matplotlib if you want a reproducible code workflow.
Observable or notebooks if you want interactive analysis.
Datawrapper if you need polished charts for publishing.
A lightweight browser tool if you just need a quick chart export.

I built one of those lightweight browser tools called CSV Graph:

https://csv.qingyanglabs.com/

It lets you paste or upload CSV data, choose columns, create line, bar, or scatter charts, and export the result as PNG or SVG. It is intentionally simple: no sign-up, no dashboard setup, and no AI-generated numbers. The goal is to make the chart from the data you actually provide.

When not to use a lightweight chart tool

A simple CSV chart tool is not the right fit for every job.

Use a spreadsheet, BI tool, or notebook when you need:

Pivot tables
Joins across multiple files
Complex formulas
Scheduled reports
Permissions and team dashboards
Very large datasets

But if you only need to turn a CSV export into a clean chart for a report, issue, README, slide, or quick analysis, a small browser-based workflow can save time.

Final thought

CSV is simple, but visualizing it should be simple too. Before opening a full spreadsheet or asking an AI tool to generate a chart from a prompt, try the deterministic path first: inspect the CSV, pick the columns, make the chart, export the result.

That keeps the numbers honest and the workflow fast.

You can also find CSV Graph on Product Hunt:
https://www.producthunt.com/products/csv-graph?launch=csv-graph