Text Banners Sampled From a Canvas
Turn a short line of text into a character banner. Choose one of four browser font styles, six fills and three row counts. Hash, at sign, asterisk and capital O produce ASCII-only output. Full Block and Dark Shade produce Unicode text art.
This is a canvas sampler, not a FIGlet font engine, an AI image generator or a video converter. It renders the text with your available fonts, then approximates the visible shapes. Small details and missing glyphs can make a banner unreadable. Banners fit a short plain-text README heading, a terminal prototype, a text-art sketch or a chat draft; check width and glyph support in the real destination, because a short input can still produce a large banner.
Settings, and How Pixels Become Characters
Enter one short line, or choose Load example for TEXT. Pick a browser font style and an ASCII or Unicode fill, then choose 8, 12 or 16 output rows and check the banner and its dimensions. Use Copy banner, or select the output field and copy manually if copying fails, and paste into a destination that retains spaces and line breaks before checking its font and wrapping.
The browser measures the text, including ink bounds, before drawing into a transparent canvas. Font settings are reapplied after resizing. Each sampling cell becomes a fill character when more than a quarter of its pixels have alpha above 128; otherwise it becomes a space. Empty side columns are cropped, while the selected number of rows stays unchanged.
Input spacing influences the rendered image, but leading and trailing blank canvas columns are cropped. This is not a reversible text encoding or a whitespace-preserving formatter. Font fallback, shaping and bidirectional text can affect the result. See MDN TextMetrics and canvas pixel reading. FIGlet uses its own text font files instead.
Load TEXT, keep Bold Block and the hash fill, then compare 8 and 16 rows. The larger setting can retain more detail, but its output can be wider. The exact banner depends on your browser font; a fixed cross-device screenshot would not represent every result.
| Cell pixels | Result | Reason |
|---|---|---|
| All alpha values zero | Space | No occupied pixels |
| One of four pixels above 128 | Space | Exactly 25% does not pass the threshold |
| Two of four pixels above 128 | # | 50% passes the threshold |
| All alpha values 128 | Space | The alpha test is strictly greater than 128 |
Why Banners Break, and What Is Bounded
Proportional fonts, collapsed spaces and automatic wrapping can break the layout. Unicode fills also depend on glyph support and display width. A monospace font helps, but cannot guarantee matching widths across fonts or destinations. Plain text copy carries characters, not font settings or color.
Tabs, line breaks, control characters and incomplete Unicode input are rejected. Text beyond either input limit is retained in the field with an error. Missing canvas support, failed pixel reading, invisible sampling or oversized raster dimensions also clear the output instead of keeping a stale banner.
Use a short label and start with the hash fill for ASCII-only environments. Compare row counts if thin strokes disappear. Canvas allocation is limited to 4,096 pixels wide, 512 pixels high and one million pixels overall. If you need styled text as an image rather than a character grid, use the Text to Image Generator.