Sometimes the thing your teammate needs is not the frame you designed. It is the original asset buried inside the frame.
A developer asks for the untouched product photo so they can generate responsive crops. A marketer needs the clean hero image for a CMS card. A vendor wants the original logo file that was dropped into a mocked-up layout months ago. What they do not want is a flattened screenshot of the final composition with shadows, text, and chrome baked into it.
That is where an original-image export workflow matters.
TinyImage is especially useful here because the plugin already covers compression, format conversion, PDFs, GIFs, video exports, and batch workflows directly inside Figma. It also has a highly relevant tutorial on bulk exporting original image files from Figma layer fills. This article is about when that workflow is the right choice, how to package the results properly, and how to avoid turning one embedded asset into three different handoff problems.
Exporting the frame and extracting the source are different jobs
Teams often blur these together.
Exporting the frame is right when the final composition is the deliverable:
- a launch graphic
- a product screenshot
- a social preview image
- a help center illustration
Extracting the original image fill is right when the image itself needs to live another life downstream:
- developers need to create their own responsive crops
- a CMS editor needs a reusable source asset
- a motion designer needs the clean background plate
- a vendor needs the photography without UI overlays
- a content team wants to repurpose the same asset in several layouts
If you hand off a flattened frame when the next person really needed the source image, they usually have two bad options: ask design to export it again or start screenshotting and rebuilding from the mockup. Both waste time.
The best use cases are usually hidden inside normal design work
This workflow matters most when Figma has become the staging ground for a lot of embedded assets:
- SaaS landing page mockups full of product photography and screenshots
- ecommerce campaign files with dozens of merch images
- presentation or deck files with vendor-supplied assets
- documentation layouts with repeated UI stills
- banner or email concepts where art direction starts in Figma but final production happens elsewhere
The existing TinyImage library already covers adjacent workflows like CMS Image Publishing Workflow from Figma and Responsive Image Handoff from Figma. This article is narrower. It is about recovering the original inputs cleanly before somebody downstream is forced to work from a composed export.
Build an extraction list before you start exporting
The messiest original-asset handoffs happen when people export reactively.
Someone Slacks:
Can you send me all the source images from that page?
Then design starts clicking random layers and exporting whatever looks relevant.
A better workflow starts with an extraction list. I like to group the assets by purpose:
developer assets: images engineering needs for implementationcontent assets: files a CMS or content team will publish directlyvendor assets: logos, photos, or plates needed by an external partnerarchive assets: originals worth preserving for future reuse
That quick categorization helps answer the important follow-up question: does the recipient need the untouched original, or do they need a reviewed derivative that is already compressed, resized, or renamed for a specific slot?
Not every source asset should move downstream untouched. Some should. Some absolutely should not.
Separate original assets from approved production variants
This is the most important rule in the workflow.
Do not mix:
- untouched source images pulled from layer fills
- final web-ready exports
- alternate crops
- preview mockups
Those are different artifacts with different owners.
A clean delivery usually looks like this:
originals/: extracted source images from Figma fillsderived/: approved cropped or compressed versions for shippingreferences/: optional mockups or screenshots showing where each asset was used
That structure prevents a common failure mode where engineering or marketing uploads the wrong file because the source and the production variant share a nearly identical name.
If the original files are going to be reused on the web, pair this extraction workflow with a follow-up compression pass instead of assuming the source images are ready to publish as-is.
Name assets by role, not by visual guesswork
If extracted files keep their mystery-filename origin, the handoff is only half solved.
Bad:
image-4.pnghero-new-final.jpgasset-copy-2.webp
Better:
pricing-page-hero-background-original.jpgfeature-grid-customer-photo-original.pngdocs-settings-panel-screenshot-original.png
The point is not elegance. It is traceability.
Anyone receiving the bundle should be able to answer:
- Where did this asset come from?
- What part of the design used it?
- Is this the original or a prepared derivative?
If you need to preserve both kinds of files, say so in the filename itself. That one small habit saves a surprising amount of back-and-forth.
Review the recovered assets before handing them off
Pulling originals out of Figma does not guarantee they are the files the next team actually wants.
Check for:
- unexpectedly low-resolution source files
- outdated photography that was replaced visually but still exists in the mockup
- logos or screenshots with the wrong background treatment
- duplicate images used in several places under different layer names
- source files that still need compression, cropping, or format conversion
This is also where you catch a subtle but important issue: sometimes the image embedded in Figma was already a compromise. It may have been downscaled, lightly edited, or swapped temporarily during design exploration. If you skip the review, the receiving team may assume the extracted asset is the approved master when it is really just the nearest convenient placeholder.
A practical Figma-to-handoff rhythm
For teams doing this regularly, the workflow can stay simple:
- Mark which layers contain assets that need to be recovered.
- Export the original image fills with TinyImage.
- Sort the files into originals and production-ready derivatives.
- Rename them by placement and purpose.
- Add one lightweight reference image or note when context matters.
- Run a quick QA pass for resolution, duplication, and version accuracy.
That is enough for most developer, CMS, and vendor handoffs.
If the destination team also needs web-ready files, follow with the right compression workflow instead of expecting them to do the cleanup themselves. That is exactly where TinyImage earns its keep: one tool can support the recovery step and the optimization step without forcing the team out of Figma.
Where teams usually go wrong
The most common mistakes are:
- exporting the whole frame when the recipient needed the source image
- sending source images without saying they are source images
- mixing originals with optimized derivatives in one folder
- assuming extracted assets are automatically publish-ready
- keeping filenames tied to internal layer chaos rather than real page roles
Those mistakes are small individually, but together they create the familiar design-handoff pattern where the same asset gets re-requested three times by three different people.
Where TinyImage fits best
TinyImage is not just for making files smaller. In this workflow, it is valuable because it helps teams recover original assets from Figma cleanly instead of treating every mockup like a dead-end composition.
That matters anytime the design file is also an asset staging area, which is increasingly most product, marketing, and content work.
If your Figma files keep becoming accidental asset graveyards, standardize an original-image export workflow. Extract what needs to be reused, label it clearly, keep it separate from shipping variants, and let TinyImage handle the recovery step before downstream teams start improvising from flattened exports.
Pro Bundle