SVG for Seating Charts: A Practical Guide for Developers

The seating chart in your ticket flow is almost certainly SVG somewhere in its life. The venue designer draws it in Illustrator or Figma, exports SVG, someone imports it into a seating tool as the floor plan, the tool binds interactive seats on top of it, and the runtime renders it as pixels to the buyer’s phone. Any one of those steps can quietly ruin the file, and the symptoms usually show up in the last one: multi-megabyte payloads, blurred logos, doubled labels, and a pan that stutters on a Pixel 6.

This post is a practical guide for developers and integrators who have to work with venue SVGs in production. It is a natural sequel to Balancing Interactivity and Performance in SVG-Based Seatmap Tools, which introduces the format and the runtime tradeoffs. Here we get into the file itself: the coordinate system to use, the export mistakes Illustrator and Figma make by default, what actually shrinks a large historic-venue SVG, and where Seatmap Pro draws the line between vector authoring and raster rendering.

The one-sentence summary

SVG is the right format for authoring a venue floor plan and the wrong format for shipping the pixels; keep the vector source clean, and rasterise before it reaches the browser.

Every ergonomic problem below traces back to that split. SVG is an authoring format: it edits well, imports cleanly across tools, and carries the physical scale of a real venue. It is not a runtime format for anything larger than a few hundred interactive shapes. Draw in SVG, publish as PNG, and the whole pipeline gets simpler.

Coordinate systems and viewBox for venues

The viewBox is the most misused attribute in a venue SVG. Get it right and the rest of the pipeline falls into place; get it wrong and every downstream tool has to guess at what your numbers mean.

A venue SVG has two natural coordinate systems, and you have to pick one:

• Venue-metre coordinates: viewBox="0 0 W H" where W and H are the venue’s real width and height in metres multiplied by a small integer factor. A factor of 100 (one unit per centimetre) is the sweet spot: the numbers stay in the low thousands, seat spacing is obvious (a 45cm seat is a rect of width 45), and the whole file remains editable in tools that snap to integers.
• Design-canvas coordinates: the viewBox is whatever Illustrator or Figma spits out, often anchored to an arbitrary artboard origin, sometimes in points, sometimes with a floating decimal precision that carries eight digits of imaginary accuracy.

The second option is what most floor plans arrive as, and it works only until someone else tries to import the file. Then the sections do not align to the seats, the underlay does not match the design, and someone spends an afternoon rescaling with the Shift key held down.

Fix it once at export. In Illustrator, set the artboard to the venue dimensions in your chosen unit and export SVG with Responsive unchecked so the viewBox is written as absolute numbers rather than being stripped for a fluid width. In Figma, size the frame to the venue’s physical dimensions (Figma’s canvas is nominally in pixels but the numbers are yours to define) and export with Include “id” Attribute on so the semantic structure survives the trip.

The rule of thumb: pick a unit, write it down, use it in every venue SVG you produce, and the entire pipeline works without a rescaling step. The Seatmap Pro editor works comfortably with any consistent unit, but the moment your files switch between “3200x2400 in points from an old artboard” and “40x30 in centimetres from a redraw”, every import turns into a fitting exercise.

What Illustrator and Figma get wrong by default

The two mainstream vector editors both export SVGs that work, and both leave artefacts that a runtime does not want. The trick is knowing which defaults to change.

Illustrator: the “embed everything” default

Illustrator’s Save As… SVG dialog defaults to embedding any imported raster as base64-encoded data inside the SVG. A high-resolution TIFF of a stadium roof, an entrance-zone photo, or a corporate logo turns into a multi-megabyte string in the middle of your file. Browsers still parse it. It just takes ten times as long as it should.

Set Image Location to Link in the SVG Options dialog if the raster is genuinely needed, and treat the linked path as a separate asset for the pipeline. Better still, replace the raster with an SVG version if one exists (most logos do), or drop it entirely if it is decoration that will be redrawn at runtime.

The second Illustrator trap is Convert to Outline on text. Illustrator converts text to path geometry by default in SVG export because it worries the reader will not have the font. For a floor plan that carries section labels this doubles the file size compared to keeping the text as SVG <text> elements, and it makes localisation impossible because the letters are no longer letters. Keep text as SVG text unless the layout genuinely requires custom letterform paths.

The third: Presentation Attributes vs Style Attributes. Illustrator’s default output uses presentation attributes (fill=“red”, stroke-width=“2”) which compress better and are easier for downstream tools to rewrite. If you switch to style attributes (style=“fill:red;stroke-width:2”) you shave a small amount off the file size but you also fight every SVG optimiser that expects presentation attributes. Leave the default on.

Figma: the invisible frames and hidden layers

Figma is cleaner than Illustrator on export but has its own class of problems. The most common:

• Frame nesting: every group becomes a nested <g> with a transform, even where a single flat coordinate would work. For a venue with hundreds of sections that adds real weight. Flatten groups you do not need before export, or run the output through SVGO to collapse them.
• Hidden layers ship anyway: elements with visibility set to hidden in the Figma canvas often still export as <g visibility="hidden"> in the SVG. That is fine for a browser but wastes DOM space and confuses tools that read the SVG structurally. Delete hidden elements you do not need, do not just toggle them off.
• Raster fills on rectangles: if you drop a photo into a Figma rectangle and export SVG, Figma embeds the raster like Illustrator does. Same fix: link it if it must exist, drop it if it does not.

The good news is that both tools produce SVG that a runtime can consume without further processing, if you set the defaults right at the point of export. It is the file that has already been round-tripped through three tools that needs help.

Optimising a large historic-venue SVG

The venues that hurt are the ones with character: a nineteenth-century opera house, a converted warehouse, an amphitheatre with hand-drawn stone tiers. The designer usually receives a scan of the architect’s plan, traces it in Illustrator, and hands back a file that lovingly encodes every capital on every column. That file is thirty megabytes.

The four levers that shrink it, in the order they pay off:

1. Path simplification

A traced path from a raster scan typically carries three to five times more control points than the eye can see. Run the file through Inkscape’s Path > Simplify or an SVGO pass with the cleanupNumericValues and convertPathData plugins enabled and the visual result is the same but the file is a third of the size. Adobe Illustrator’s Object > Path > Simplify does the same job in Illustrator’s editor.

For a venue outline this is safe: nobody is going to zoom close enough to notice a missing sub-pixel bump on a wall. For section boundaries that will be bound to interactive shapes, be a little more conservative so the click-target stays where the designer put it, but a two-decimal-place precision is still fine.

2. Symbol and use for repeats

Historic venues repeat: fifty identical column bases, four hundred identical seats, twenty identical row markers. If each one is a full copy of the same geometry, you are paying for the same paths hundreds of times.

Define the geometry once in a <symbol> in <defs> and reference it with <use href="#seat" x="..." y="..."/> at each instance (older tools still emit xlink:href, which browsers continue to support). A seat with fifteen path commands drops to a two-attribute reference. On a 6,000-seat venue this alone can halve the file.

Illustrator does not do this automatically. Figma does it inside its own component system but exports the components expanded. If you care about the size of the shipped file, add the symbol-and-use pass after export, either by hand for a small set of repeats or via a scripted SVGO pipeline.

3. Coordinate precision

The default numeric precision from every vector editor is eight decimal places. For a venue in metres that is angstrom-level precision. Nobody needs it and browsers do not care.

Running SVGO with --precision 2 (or the equivalent config on the modern plugin API) rewrites every coordinate to two decimal places and shaves a surprising amount off a file with tens of thousands of points. On the same 6,000-seat example that halved with symbol reuse, precision truncation removes another ten to twenty percent.

4. Strip the editor cruft

The bottom of every Inkscape SVG carries a <sodipodi:namedview> block, an <inkscape:*> namespace, and metadata about the user who saved it. Illustrator drops in its own <i:pgf> block. Figma leaves layer names as id attributes shaped like “Rectangle 47 Copy 3”.

An SVGO pass with the removeMetadata, removeEditorsNSData, removeUselessDefs and cleanupIDs plugins removes ten to thirty percent of the raw text on a typical file. It never changes the rendering.

For a serious pipeline, wire this into whatever step brings the SVG in. For a one-off floor plan, run it in Inkscape once and check in the result. Either way it is free money.

SVG as an editor underlay, PNG for the runtime

Seatmap Pro uses a split pipeline: SVG at authoring time, PNG at render time. That is not an accident.

The Seatmap Pro editor imports SVG as an underlay for the venue floor plan. The designer imports the architect’s plan, sees it behind the interactive sections and seats, and binds each non-general-admission section to a region of the underlay by clicking on the drawing. The SVG is the source of truth for the visual layout throughout authoring, editing, and version control.

At publish time, that SVG is rasterised server-side to a PNG background at the zoom levels the runtime needs. The buyer’s browser receives:

• A PNG of the venue background, sized for the viewport and DPR.
• JSON metadata describing the section polygons and seat positions.
• The renderer, which draws interactive seats and section overlays on top of the PNG using WebGL, or Canvas 2D as a fallback.

The reasoning is exactly what we cover in WebGL vs Canvas 2D for Seating Chart Rendering: a multi-megabyte SVG DOM is a rasterisation bottleneck on every pan and zoom, and a pre-rasterised PNG is a trivial background image. The interactivity is in the WebGL layer; the picture is in the PNG.

That means the SVG only has to be good enough to author with. It does not have to be small enough to ship. Keep the authoring version clean and edit-friendly, and let the publish pipeline produce the runtime asset. The /blog/svg-basics-for-seating-charts/ post has the deeper history of why this split emerged.

When to rasterise instead of vector-import

Not every source is worth vector-tracing. If the venue comes to you as a photo, a bitmap scan, or a stylised marketing render that was never designed to be edited, the right move is to import it as a raster underlay from the start.

The Seatmap Pro editor accepts both. Vector import gives you an editable underlay with lossless zoom; raster import gives you a fixed-resolution background image. The trade-off:

• Vector import: infinite zoom, small file, editable in a vector tool. Best for architect’s plans, DWG exports, Illustrator or Figma originals.
• Raster import: resolution-locked, heavier at high resolutions, but faithful to the original. Best for photographs of historic halls, marketing renders where the artwork is the product, and any source that would take days to retrace.

For a mid-scale venue whose plan already exists in a design tool, vector is the right answer every time. For a historic amphitheatre whose “plan” is a hand-drawn watercolour, tracing it in Illustrator loses the character of the drawing and takes a week; rasterising it at a high enough resolution to zoom the way the renderer needs is the pragmatic choice. There is a companion post on this decision in the Q3 backlog; for now, the shorthand is: if the drawing carries visual identity that would not survive a retrace, rasterise.

The bound-section label trap

One warning that catches everyone the first time they import venue artwork with baked-in section names.

The imported SVG typically carries the section labels as vector text or outlined glyphs, because that is how the designer laid out the map: “Orchestra”, “Balcony”, “VIP Left” written in a specific typeface at a specific position. When you bind a section in the editor to a region of that underlay, the renderer then draws its own live label at the section’s anchor point, driven by the schema data. Both labels appear at once. The map looks doubled.

The instinct is to fix the drawing: strip the baked text out of the SVG, or run a filter that removes any <text> inside a section polygon. Do not do this. It breaks the next re-import when the designer sends an updated plan, and it fights the source of truth: the drawing did have the label the designer intended.

The correct fix is at the schema level. For each bound section that already carries a drawn label, set labelStyle.visible = false on the section so the renderer stops drawing its live label. The drawing wins. If the section later moves and the drawing goes stale, flip the setting back and let the renderer draw the label at the new anchor.

This is a well-worn trap in customer support and has caught teams working on rasterised backgrounds too: the raster still has a baked name on it, the schema still ships a live label. Same fix, same schema setting, regardless of whether the underlay is SVG or PNG.

A short SVG checklist for developers

If you have read this far, you probably want a checklist to run against the next venue file that lands on your desk. In order:

1. Does the viewBox use a consistent, documented unit across your files? If not, rescale to metres or centimetres and record the choice in the venue metadata.
2. Are any raster images embedded rather than linked? Link them, or replace them with SVG equivalents, or drop them.
3. Is text vectorised? Keep it as SVG text unless the layout genuinely needs custom glyph paths.
4. Are repeating shapes (seats, columns, row markers) duplicated as full paths? Move them to <symbol> and <use> references.
5. Is coordinate precision higher than two decimal places? Truncate.
6. Does the file carry editor metadata (sodipodi, inkscape, Illustrator PGF)? Strip with SVGO.
7. When you re-import the cleaned file into the editor, do the section anchors still line up? If not, you scaled or translated somewhere you did not mean to.
8. Are section labels appearing twice on the rendered map? Turn off the live label on the bound sections, do not strip the drawing.

Each of these takes a couple of minutes on a clean file and a couple of hours on one that has drifted through three tools. The pipeline pays for itself in the second week.

Where to go next

• Balancing Interactivity and Performance in SVG-Based Seatmap Tools: the format and the runtime tradeoffs, and why the industry moved away from shipping SVG directly to the browser.
• Seating plans. How do we render?: the broader history of rendering approaches from HTML tables through SVG, Canvas, and WebGL.
• WebGL vs Canvas 2D for Seating Chart Rendering: the runtime side of the pipeline that consumes what your SVG becomes.
• Venue Editor user guide: the practical mechanics of importing an SVG underlay, binding sections, and managing the view area.
• The art of design, or how can a rookie create a Colosseum seating map: a companion piece on how a non-designer approaches a complex historic venue.
• Book a demo: bring the venue file you have been struggling with, and we will walk through the import together.