CMS Image Publishing Workflow from Figma

Publishing images to a CMS sounds easy until the same avoidable problems keep showing up: the hero is 4 MB, the mobile crop cuts off the product, the developer gets three different filenames for the same asset, and the content team is left guessing which format belongs where.

That is why “just export the images from Figma” is not really a workflow. If your team ships landing pages, changelog posts, case studies, blog content, help center screenshots, or CMS-driven product pages, you need a repeatable handoff from design to publishing.

TinyImage is useful here because it keeps image compression, format conversion, PDF export, GIF or video export, and batch processing inside Figma. But the real win is not only smaller files. The real win is giving whoever publishes the content a package they can use immediately without re-compressing, renaming, or second-guessing anything.

What usually breaks between Figma and the CMS

A content editor or marketer does not care that the export looked good on the designer’s desktop. They care that:

• the CMS accepts the file size
• the crop still works on the live template
• the filename is understandable
• the asset matches the right page section
• the upload does not slow the page down

The biggest mistake is handing off a pile of image files without context. The second biggest mistake is exporting one giant master file and expecting the browser or CMS to clean it up later.

If you have ever watched a marketing team re-run assets through TinyPNG, rename them in Finder, and manually guess which image belongs to which module, that is the gap this workflow is meant to close.

Start with publishing roles, not export settings

Before touching TinyImage, decide what the CMS actually needs.

For each image set, answer five questions:

1. Who uploads the files: developer, marketer, content editor, or agency client?
2. Which template will use them: homepage hero, blog inline image, comparison table, help center screenshot, social preview, or docs asset?
3. Does that template need one crop or separate desktop and mobile variants?
4. Which formats are acceptable in the publishing stack: JPG, PNG, WebP, AVIF, SVG, PDF, GIF, or MP4?
5. Is the goal visual fidelity, smallest size, fastest publishing, or all three?

That sounds simple, but most CMS image confusion comes from skipping those decisions until after the exports already exist.

If your team is still deciding between formats, SVG vs PNG vs WebP for Figma exports is a useful companion read before you standardize the workflow.

Build an export package the CMS team can trust

A good CMS handoff package should feel boring in the best possible way. Nobody should need to ask what a file is for.

My preferred structure looks like this:

• one folder per page or campaign
• one subfolder per image role if the page is asset-heavy
• filenames that describe placement, not just design intent
• only the final variants, not every experiment

For example:

• homepage-hero-desktop.webp
• homepage-hero-mobile.webp
• feature-grid-analytics-card.png
• case-study-quote-portrait.jpg
• [email protected]

This is where TinyImage helps in a very practical way. You can compress inside Figma, batch export multiple assets, and use cleaner naming conventions before anything ever reaches the CMS. If your team already relies on folder-based exports, the tutorial on exporting images with custom folder paths from Figma using TinyImage is worth standardizing.

Pick formats by content type, not by habit

A common bad habit is exporting everything as PNG because it “feels safe.” That usually creates larger files than you need.

Instead:

• Use WebP or AVIF for photographic or marketing imagery when the publishing stack supports them.
• Use PNG when transparency matters or when UI screenshots need lossless clarity.
• Use SVG for simple vector graphics and icons.
• Use JPG only when it is the most practical fallback for older workflows or CMS limitations.

The right answer depends on what the image is doing. A product screenshot inside documentation does not need the same treatment as a homepage lifestyle image. A chart image inside a blog post may need sharper text edges than a background photo.

TinyImage is strongest when the designer makes these choices deliberately instead of exporting first and optimizing later. If page speed is the main concern, How to optimize Figma exports for page speed is the nearest related article in the library.

Handle crops before the handoff, not after upload

CMS teams often get blamed for “bad crops” that were inevitable from the source file. A single wide desktop asset rarely solves mobile, card, thumbnail, and inline usage at the same time.

If a subject, UI state, or text overlay matters, define that in Figma before export:

• mark the approved focal point
• create separate mobile-safe crops when needed
• avoid embedding essential text into imagery if the crop may change
• review screenshots at the actual aspect ratios used by the CMS template

This matters even more for product screenshots, SaaS changelog images, and help center visuals. The desktop shot that looks generous in Figma can become cramped or unreadable once a CMS card template squeezes it down.

Review the upload like a publisher would

Before sending files onward, do one final pass that mirrors the real publishing environment.

Check:

• file size against the actual CMS or team budget
• image dimensions against the template’s rendered slot
• filename clarity
• crop quality on desktop and mobile
• whether any screenshot text becomes soft after compression
• whether retina exports are truly needed or just assumed

This review is especially important if the same asset family will also be reused in ads, decks, or HTML emails. TinyImage can support all of those outputs, but the CMS package should still be curated for the CMS job first.

If the page uses many source images, it can also help to downsize oversized image fills in the Figma file before exporting. That reduces both Figma bloat and handoff confusion, not just final file weight.

A repeatable publishing workflow

For teams that publish from Figma into a CMS every week, this is the simplest version of the workflow I would formalize:

1. Map each image to a real CMS slot before export.
2. Decide the final format per slot.
3. Create separate crops where mobile or thumbnails need them.
4. Compress and export with TinyImage in batches.
5. Name files by placement and content, not internal design jargon.
6. Deliver a clean folder package with only approved assets.
7. Spot-check the live page after upload and adjust presets if one template keeps causing trouble.

That last step is underrated. The first upload cycle should improve the next one. If the blog template always needs lighter inline screenshots, or the help center cards always soften text too much, update the preset instead of relearning the lesson next month.

Where TinyImage fits best

This workflow is most useful for:

• marketing teams publishing frequent CMS updates
• agencies handing assets to non-technical clients
• design teams supporting Webflow, Shopify, Contentful, Sanity, Ghost, or custom CMS stacks
• product marketers maintaining changelogs, docs, and launch pages

TinyImage does not replace judgment about what the CMS should display. What it does is remove the wasteful middle step where good Figma assets become bloated, renamed, recompressed, and misfiled before they ever go live.

If your team wants a cleaner Figma-to-CMS handoff, start by standardizing the naming, crop rules, and format decisions around TinyImage. Once those rules are visible, compression stops being a last-minute cleanup task and becomes part of a publishing workflow that actually scales.