Rotated parent frame causing layer positioning issues

This usually occurs if the parent frame has been rotated to something other than 0 degrees (e.g., "-90" or "180") before the contents were added, which throws off the positioning of the child layers. To resolve this, you can create a new unrotated frame with the same dimensions and copy or drag the child layers from the original rotated frame into the new frame with no rotation set.

Text layer bounding box (cropping)

The other thing that might be throwing off the position or cropping a text layer is if the size of the text box doesn't match the size of the text itself; for example, if there are multiple lines of text, but the "bounding box" height is only very short, this will cause the positioning to be offset incorrectly. To resolve this, you can tweak the height of the bounding box to match the size of the text content itself.

Blurred SVGs with shadows in Safari

There is a known issue with SVGs that contain any drop shadows in Safari, where it will rasterize the vector into pixels instead, and that causes it to look less sharp.

One suggestion in the thread above would be to split the shadow layer and button/content layer onto two different layers; so the button layer above without a shadow would still render as a sharp looking SVG in Safari, and the layer underneath would only serve to add the shadow behind it.

Alternatively, you could also override the image format just for that button CTA layer to "PNG" via the plugin, and also override that layer's scale setting to @2x retina, and this would ensure the CTA gets exported as a 2x PNG image, which will keep it looking sharp and avoid the SVG shadows issue in Safari.

Colors/gradients in GIFs look a bit grainy

GIFs are a bit different from normal JPG/PNG images, as they can only contain a maximum of 256 colors. If you're using highly detailed images or gradients with lots of color variation, it's expected that it won't look as sharp or have the same color accuracy as the original images used as the source of the GIF due to this limitation of the GIF format.

Transparency isn't showing in GIFs

The GIF file format supports either 0% opacity or 100% opacity, but nothing in between. This means that you can have an animated GIF with a completely transparent background behind elements that are completely opaque and visible. This means that layers either need to be completely transparent or not; any layers with lower than 50% opacity will be transparent, while any layers with opacity greater than 50% will be opaque.

Flagging transparent GIFs in Figma. By default, your GIF exports won't include transparency. If your GIF does require transparency, please add the word transparent anywhere in your Figma layer's name.

Where to host .mp4 video files

For adding videos to Bannerify, the plugin will load up any URLs that link directly to a .mp4 file, so unfortunately, URLs pointing to Vimeo/YouTube or any web-based player-type links won't be usable in this case. One good option for hosting videos is Backblaze B2; you can sign up for a free account that gives you 10gb of free storage, and if you create a public storage bucket, you should be able to copy/paste the links for any video files you upload to it and drop that link to the .mp4 into Bannerify. Another popular file hosting option is Dropbox, which will let you upload your .mp4 file and use that link in the Bannerify plugin; Bannerify will automatically handle changing the ?dl=0 to ?raw=1 to ensure the link points directly to the video file (rather than the Dropbox website player).

Thin white line around image exports

Occasionally some images will contain a faint, thin white line around the edges. Figma does this if a layer isn't positioned on a rounded pixel value (e.g., Y: 156.76 or X: 56.3) will automatically result in this sub-pixel line getting included in the export. Bannerify tries to automatically round these values for layers that allow resizing via the Figma Plugin API, but to manually resolve the issue (if needed), please ensure that your layer positions are all rounded pixel values.

High-res banners not exporting to MP4

If you're exporting high-resolution banners to MP4 video from the plugin, sometimes Figma hits its 2gb memory limit ceiling and can't render out the video file to .mp4 directly. To workaround this, you can export your banners from Bannerify to the WebM format instead and then convert the exported .webm video files to .mp4 outside of Figma using the Handbrake video transcoder.

Google Ads not being validated

There are a couple of common reasons why an HTML banner might not be uploading or being validated by Google. Usually, the banner file size will be too large, or the banner sizes don't exactly meet the "standard" sizes. You can use these services to validate your banners for Google Ads or DoubleClick before uploading them.

Exported HTML banner is not animating or playing in the browser

If your exported HTML banner looks frozen, does not animate, or works in Bannerify's preview but not when you open the exported HTML file in a browser, check whether an ad blocker or privacy browser extension is enabled. Some extensions can block local or ad-related HTML files from running correctly. Temporarily disable the extension for the local preview file, open the export in another browser, or upload the banner to your normal preview/staging environment and test it there.

Blank file extensions using Figma desktop app on Windows

There's a known issue with the Figma desktop app (only on Windows), which also happens for normal file exports from Figma. When you go to save your file, you may see an "all files" label. If you ignore this and continue by clicking "Save," it should still save the file with the correct extension and allow you to open it as expected after it has downloaded to your computer. If it still saves the file with a blank extension, you should be able to rename the file to manually append the correct extension to the file name.

Google HTML validator converting SVG elements with drop shadow into PNG (when uploaded via mobile)

For some reason, when uploading a banner .zip to the DCM Validator via a mobile device (eg. iPhone) browser, the validator will automatically convert any SVG elements that contain a drop shadow into a PNG instead, causing it to look more pixelated in the preview.

Pixelated image exports

If you're exporting banners while the image assets in Figma are still progressively loading, they may be exported looking pixelated, as the image wasn't fully loaded in the Figma file before it was exported. To resolve this, please ensure that all of the images have loaded 100% and are looking sharp inside the Figma file before exporting your banners with the Bannerify plugin. To help further with solving this issue, you can use the "Downsizer" feature in TinyImage to shrink down your image fills to match their layer size, which will shrink their file size and ensure they load much faster in your Figma file.

Adding aria-hidden='true' attributes to layers

If you need to include aria-hidden attributes for accessibility reasons, you can do this per-layer by including aria-hidden in your Figma layer name; this will automatically include aria-hidden="true" to that HTML element when the banners are exported to HTML.

VPN may be required in China

Please note, if you're in China, the accounts server may be blocked by "The Great Firewall of China." If you're seeing an activation error, despite using a valid key, you will likely need to use a VPN to resolve the issue.

'An error occurred while loading the plugin environment'

This may happen in the Figma desktop app if the Use Developer VM debug setting in Figma is enabled by mistake; you can make sure it's turned off by right-clicking anywhere on your Figma canvas, hovering over Plugins, then hovering over Development, and making sure that the Use Developer VM is unchecked; after it is unchecked (and does not have a tick icon next to it), re-running the Figma plugin should work as expected.