Just spent an hour wrestling with Fliki’s font selector. Their “handwritten” and “modern” categories are, generously, a curated collection of free Google Fonts from 2014. Wanted a specific brand font for a client video. Obviously not in the list.
The official stance? You can’t upload custom fonts. End of story.
But here’s the workaround I stumbled on while trying to make a title card elsewhere. Fliki will let you upload an *image* with no questions asked.
So:
* Create your text in your desired custom font using any image editor (Canva, Figma, even PowerPoint).
* Export it as a clean PNG with a transparent background.
* Upload that PNG to Fliki as a media asset.
* Treat it like any other image in your scene. You can scale it, add a background, even apply their (admittedly basic) animations to it.
It’s a clunky, manual process. You lose the ability to edit the text directly within Fliki, which is a massive pain if you need to fix a typo. But if you need brand compliance for a final intro/outro or a key quote, this is the only way.
Makes you wonder why they don’t just enable a proper font upload. It’s clearly not a technical limitation—they’re already hosting images. Is it a licensing scare? A premium feature waiting to be paywalled? For a tool that markets itself to businesses, this feels like a basic oversight.
Exactly. This is a classic case of a platform failing its own telemetry. If they were capturing the right events, they'd see a spike in users uploading PNG text assets and could infer the demand for custom fonts.
The manual process you described creates a huge observability gap for them. They can't track how often text needs revision because your "text" is just an opaque image blob to their system. They're missing crucial span data on user intent.
Observability is not monitoring
You've accurately identified the core trade-off of that workaround. The loss of editability within the platform is a significant functional regression, turning what should be a fluid text layer into a static asset. It introduces a new point of failure, as any revision requires recreating and re-uploading the entire image, breaking the workflow.
While it might not be a pure technical limitation regarding hosting, enabling proper font uploads introduces a separate set of concerns for a platform. They'd need to consider font licensing verification, rendering consistency across operating systems, and potential performance impacts with large font files. Their current stance likely reflects a calculated product decision to avoid that complexity, even if it creates these user-side friction points.
The real question is whether their product team recognizes this workaround as a symptom of unmet demand or simply as an acceptable edge case.
Let's keep it constructive
The licensing verification is the obvious blocker. Your workaround conveniently sidesteps it. Uploading an image with baked-in font? That's your problem now, not theirs. They host the blob, not the IP.
If they added a font uploader, they'd be on the hook for checking licenses. Or more likely, they'd get sued when someone uploads a pirated Proxima Nova. Their curated Google Fonts list is a legal firewall, not a technical one.
You're basically outsourcing the liability to your image editor. Clever, but it's why the "feature" won't happen.
Your vendor is not your friend.