Planning an SVG blob means choosing five explicit inputs — vertex count, irregularity, canvas size, fill color, and a seed — before you touch a generator, so the resulting vector markup is reproducible, predictable, and ready for its destination. A good plan is short: it lists the visual goal in one sentence, fixes the canvas dimensions and color, decides on the rough silhouette density, and reserves a way to record the seed. With those five facts locked in, the actual generation is a single click and the output is a compact, viewBox-correct SVG document you can copy, download, or paste straight into your project. Skipping the planning step is the most common reason a blob looks wrong later: designers adjust random knobs, forget which seed produced the silhouette they liked, and end up re-rolling the shape until a deadline forces a compromise. The plan is what separates "I got lucky" from "I can ship this."
What a planning workflow looks like for an SVG blob
A planning workflow is a checklist you run before the first click, not after. It answers four questions in order: where the blob will live, how big it needs to be, how much silhouette detail the destination can absorb, and which color it has to match. Once those answers are written down, the generator becomes a deterministic function: equal inputs plus equal seed always produce equal markup. The SVG Blob Generator exposes that determinism through a small, fixed set of controls rather than a free-form editor, which is what makes a plan possible in the first place.
The opposite of planning is exploration, which has its place — you can hit Randomize Shape a few times to find a silhouette you like — but exploration only pays off if you record the seed that produced it. Treating randomize as a search engine for good seeds, and the planning fields as the fixed context, keeps the workflow honest. You can read the rest of this guide as a planning contract: a set of inputs you decide up front, a single generation step, a recording step, and a validation step.
Inputs to lock in before you generate
The generator accepts exactly four user-controlled inputs and one hidden input (the seed). Lock these in before you start so the preview matches the destination, not the opposite.
| Control | Accepted range | Role in the plan |
|---|---|---|
| Vertex count | 3 through 12 (integer) | Sets the silhouette density. Low values feel like soft pebbles; high values feel like rounded stars. |
| Irregularity | 0 through 100 | Radial variation per vertex. Zero produces a smooth circle; higher values add asymmetric bumps. |
| Canvas size | 256 to 1024 px (square) | Sets width, height, and matching viewBox. Pick the size your destination actually needs. |
| Fill color | Six-digit HEX only | Single strict fill for the path. No gradients, strokes, or shadows are added by the tool. |
| Seed | Unsigned 32-bit integer | Determines radius variation. Same settings plus same seed equals identical markup. |
Invalid values are rejected by the generator rather than silently clamped, so the plan either works or fails loudly. The browser's native color picker supplies a valid HEX during normal interaction, which means your color plan only breaks if you paste an unsupported string. The canvas size you pick is what gets written into the SVG document; the on-page preview may be visually scaled by the surrounding layout, but the file itself keeps the dimensions you requested.
Generate the blob using the SVG Blob Generator
Once the four planning fields are pinned, the actual generation is short. Open the SVG Blob Generator and follow the steps below.
- Set the vertex count, irregularity percentage, canvas size, and fill color to match the values you decided on.
- Press Randomize Shape until the preview fits your design intent, then read the seed displayed under the result and write it down with the other four values.
- Copy the SVG markup from the visible text area, or click Download SVG to receive a file whose name contains the seed you just recorded.
- Paste the file or the markup into the destination editor, browser, email client, or content system where it will ship.
- Confirm the destination renders the markup correctly and that the dimensions match what you planned.
Randomize Shape is the only action that asks the browser's cryptographic random source for a new seed, so the displayed graphic cannot drift on its own while you edit other controls. If you later change vertices, irregularity, size, or color without pressing randomize, the seed stays the same and the silhouette evolves predictably. This is the behavior the planning workflow leans on: every setting change is recorded, every random change is captured by the displayed seed, and the path data plus rounding remain stable across sessions.
Recording the recipe so you can rebuild it later
Reproducibility for this tool is not a vague promise; it is a contract built from the seed plus the four explicit inputs. Equal settings and the same seed produce the same points, the same path data, and the same serialized markup, with coordinates rounded to two decimal places when written out. That rounding is a feature, not a loss: it keeps the file readable while preserving more precision than the available canvas sizes can use.
| Item to record | Why it matters |
|---|---|
| Vertices | Drives path command count and the rough shape density. |
| Irregularity | Sets the radial spread applied to each vertex. |
| Canvas size | Determines width, height, and viewBox written to the file. |
| Fill color | Becomes the strict six-digit HEX on the single path element. |
| Seed | The only source of randomness; required to rebuild the exact same path. |
For a longer workflow, the document-the-steps companion guide walks through a fuller project log format, but the five fields above are the minimum you need. The downloaded file's name already encodes the seed, so renaming it later removes that breadcrumb — save the value separately if you intend to keep iterating on the same shape.
Sanity checks after the SVG leaves the tool
The tool intentionally outputs minimal markup: an explicit width and height, a matching viewBox, an accessible image label, exactly one path, and one strict six-digit HEX fill. There are no gradients, strokes, shadows, clipping paths, animations, CSS classes, metadata, optimization passes, or raster fallbacks in the file. If your destination needs any of those, plan to add them in a vector editor after the download rather than expecting them from the generator.
Some destinations impose their own restrictions even when the markup itself is valid. Inline SVG and data URLs are the two most common friction points: certain email clients and content sanitizers strip them by policy, not by syntax error. Test the exported file in the actual browser, editor, or system that will display it before treating the plan as complete. The W3C SVG 2 specification defines the underlying path commands used in the output, including move, quadratic curve, and close-path syntax, so the markup follows standards rather than a private dialect.
Two extra checks belong in any plan. First, high irregularity can create tight bends or unbalanced visual mass; inspect the preview at both a large display size and the small size where the blob will actually appear. Second, if the shape sits behind text, confirm real contrast against the actual background and leave sufficient padding, because the tool's canvas margin is a layout guard, not a typography guarantee.
When a blob is the wrong tool for the job
A blob is decorative geometry — not a mathematical circle, a logo clearance rule, a geographic outline, a biological model, or a randomized identity mark. If the destination needs any of those, the plan should stop here and reach for a different shape source. Increasing vertices can make the silhouette more detailed but it does not increase exported coordinate precision; the tool rounds to two decimal places regardless of vertex count. Choosing a blob for a job a circle or a rectangle would solve just as well adds planning overhead with no visual benefit.
The plan also fails honestly when an input is wrong. There is no automatic clamping, so picking a color that is not a six-digit HEX, asking for thirteen vertices, or requesting a non-square canvas returns a rejection rather than a quietly mutated result. Treat that rejection as planning feedback, not a bug, and update the inputs before re-running the generator.
For a deeper look, see Generate an SVG Pattern Correctly: A Tile-First Workflow.