Design files are becoming text

Marketing design at scale has a new face – JSON.

Photoshop, InDesign and Illustrator were built long before LLMs existed, and their formats were designed for one app to open. Design work sits in blackbox files (.psd, .ai, etc.) that other software can't read. That's where JSON comes into play.

You don’t need to be technical to read JSON – it’s structured text describing your design as objects and their properties. No specialized software to open it, and any LLM will easily read it.

{ "width": 1080, "height": 1080, "pages": [ { "children": [ { "type": "text", "x": 80, "y": 120, "text": "Summer sale – 40% off", "fontSize": 72, "fontFamily": "Inter", "fill": "#111111" } ] } ] }

That's the whole design – position, type, copy, color – all of it in plain sight. Change "40% off" to "50% off", bump fontSize, swap fill for your brand token, and you've edited a design without opening a design tool. A human can read it and a machine can rewrite it, without the format getting in the way.

Designs live inside workflows.

A JSON design is a living object your systems continuously interact with: plug it into any pipeline and it gets updated, re-rendered and published on a schedule or on a trigger. A price changes or a campaign goes live, and the creative updates itself without anyone opening an editor.

Generate designs from a prompt.

An LLM can write valid JSON directly, so "make 20 banner variants for this campaign" is a single API. It’s early days, but it’s getting better fast.

Bulk personalization at scale.

Swap text, images and brand tokens programmatically to render thousands of localized or per-customer creatives from one template.

Version control for design.

JSON diffs cleanly in Git, so you can review changes and roll them back exactly like code.

Automated brand compliance.

Because every object and property is readable, you can validate designs against brand rules and flag issues before publishing.

Works everywhere.

Designs move freely between your editor, backend, renderer and third-party tools.

JSON is the file format. The editor is still the interface, and nobody positions text by typing coordinates. Instead:

Every canvas action maps to a property change. Move an element and x and y change, resize it and width and height change – and so on for everything else the toolbar exposes. The editing experience is the same as any design tool; only the saved file is different.

Priya

Humans and machines can edit the same file at once

Because a design is data, it can be stored like any other data: a row in your database, an object in S3 or a file in Git. Anything with access can read and write it:

None of these need a copy. They all read and write the same record, so there is no export step, and no production version that quietly goes out of sync from the original. Normal concurrency rules apply: last write wins by default, and you add locking or versioning if two writers can collide.

In practice a designer builds and maintains the template, and scripts fill it in and re-render it. The template is the only thing a human has to touch.

A readable file still has to become an image. That is a separate service: it takes JSON plus the referenced assets and returns a statics like PNG, JPEG, PDF, animated GIFs or videos like MP4 or WEBM. Usually it runs a headless browser or a server-side rendering library.

A full automated pipeline is three steps:

const design = JSON.parse(template) design.pages[0].children[0].text = product.title design.pages[0].children[1].src = product.image

const png = await render({ design, format: "png" })

You can run that in a loop for a thousand of creatives, or on a webhook when a parameter gets updated.

HTML, CSS, YAML and Terraform all became automatable for the same reason: they are structured text. Design files are one of the last formats where that is not the default.

Many teams go that way – render HTML templates in a headless browser and screenshot them. But it quickly falls apart when designers get involved. HTML is made for browsers to display. It has no built-in way to select an element, drag it, rotate it or manage layers, so letting a designer edit it means building all of that yourself. But even then CSS layout is a poor fit for the absolute positioning that design work assumes. There's no font-size-to-fit and no snapping. Print is also weak: browser print output gives you RGB PDFs with limited control over bleed, color profiles and PDF/X conformance.

HTML-to-image may work well when only developers ever touch the template. A design document format is the answer when someone needs to open it on a canvas.

You import most of them, and rebuild/fix some by hand.

JSON, Figma, SVG, PDF and PSD all convert into the same design JSON in the browser; JSON, PDF and PSD also load on the server. Your layer structure carries over, so text arrives as editable text and vector paths stay vector instead of being flattened into a picture of themselves. In practice you should expect ~90% of designs to come through correctly; some cleanup may be necessary, but you don't have to rebuild the design from scratch.

Every import produces schema-validated JSON, so bad input fails at the boundary instead of surfacing on row 400 of a batch.

A single-page raster render is typically in the hundreds of milliseconds to low seconds, dominated by font and image fetching rather than by drawing. Multi-page PDFs and video are slower and largely depend on complexity.

What was architectural weakness is now strength: every design is independent, so 10,000 renders is a queue for a bunch of workers. Cache fonts and remote images aggressively, because the same logo fetched 10,000 times is the most common source of slowness. If you self-host, a browser-based renderer costs roughly what any headless-browser workload costs; if you use a render API, you're paying per asset and should model it against your worst-case campaign volume.

Once non-designers and LLMs can write to the file, you need constraints in the file:

You'd need 5 pieces here: a schema, an editor, a renderer that handles fonts correctly, asset storage, and template management. The schema and the storage are easy. The editor and the renderer are where the years go – text layout, font fallback, undo, snapping, and getting the canvas and the renderer to agree pixel for pixel.

Build it if creative editing is your product. Buy or embed it if creative editing is a feature inside a product that's about something else.

JSON solves readability. These are the problems that remain, and they're the ones that actually break pipelines.

This is the number one failure mode of templated design. A product name might be three words or nineteen, and the German translation of it runs about 30% longer than the English. Add Arabic and the text runs the other way entirely. The layout that looked perfect with sample copy breaks on row 400 of the feed.

The format helps only because it makes the fix programmable. You still have to choose a strategy per text element and store it in the design:

This text box was designed around the English headline, which takes two lines and leaves room for a button underneath. Switch the language to see how each strategy deals with what comes out.

The German version runs to three lines in a box that holds two, so this is where the four strategies start to behave differently.

Test with your longest locale and your longest real product name, not with lorem ipsum. Then make overflow a validation error before you discover it in a customer's ad.

Fonts are the most common cause of "the render doesn't match the preview":

If your designs end up in print, find out early whether your renderer can produce what a print shop asks for: CMYK color, a bleed area, trim marks, spot colors, overprint and PDF/X files. Most browser-based rendering outputs RGB and gives you very little control over any of these. There are workarounds, such as rendering at a high DPI and converting with an ICC profile and Ghostscript, or handing the job to a print-specific renderer, but they have to be planned from the start. Print shops run preflight on every file they receive, and a missing bleed box or an RGB image is enough to send it straight back, so it is far cheaper to find that out on your first test PDF than on your first real order.

Fonts, images and video are referenced by URL. You need to host them, keep those URLs valid, and accept that a design from two years ago renders differently if an image behind it moved. Snapshot assets alongside templates if you need reproducibility.

Change the shape of your JSON and existing templates break. Version it, keep changes additive, and write migrations for anything else.

LLMs are good with copy, variants and property edits, and a decent template gives them a lot to work with. In my experience, roughly 50–60% of the variations an LLM produces from a good template come out usable, so the practical approach is to generate several and filter. Keep the set of editable fields small and validate every output before it renders. Overlapping elements and text that drifts off the canvas are the usual failures, and a check catches them before anyone sees them.

If the renderer uses different font handling or text layout logic than the canvas, output won't match the preview, and the mismatch will show up in the one asset a customer complains about. Use the same engine on both sides.

No. Designers work on a canvas like they would in any design tool, and the editor writes the JSON for them. Lock the template so only the intended fields can be edited. A developer is only needed once, to wire the pipeline that fills the template with data for bulk generation.

Yes. There's one format. Programmatic output loads back into the editor like anything else, which is what makes "generate, then have a human fix it" possible.

Wherever you keep other data: a JSON column in your database, or an object in S3. A simple design is a few KB and a complex multi-page template can reach hundreds of KB. A design grows into megabytes when images or SVGs are embedded in the file as data instead of linked by URL. Uploading media to storage and referencing it keeps the file small, and either size is easy to store.

Useful for template changes, where you can see that a font size or a color token changed. The diff of a wholesale layout rewrite is large and hard to read, so pair it with pictures: because a design renders straight from its JSON, a CI step can render the before and after versions and attach both images to the pull request. Designers and reviewers get a visual review next to the line-by-line one.

For editing and variants, yes, reliably, especially with a schema in the prompt and validation on the output. For composing an original layout from a blank page, results are inconsistent. Treat it as a fast junior that needs a template and a reviewer.

No. You can construct and render JSON entirely in code. The editor exists for the moments a human wants to see and adjust the thing.

Yes. A design can hold video clips, GIFs and audio, elements can carry animations, and each page has a duration, all in the same JSON. The same render step that produces a PNG can produce an MP4 or a GIF. Video takes longer to render than a still image, so allow for that in bulk runs.

Rendered output is a flat image or PDF, so accessibility lives in what surrounds it – alt text, captions, tagged PDFs. Because the source is text, you can generate alt text from the same data that filled the template.

The Polotno SDK is built this way: one JSON schema, a visual editor on top of it, and a render API that turns the same JSON into files.