The Unglamorous Half of Owning a Brand

A streaming service needs considerably more artwork than anybody expects, at sizes nobody remembers. Vodlix lists what is required, states the dimensions and the file limits, and shows you the result before you save it.

Create Your Free Account See Our Pricing
The Unglamorous Half of Owning a Brand

Nobody Warns You How Many Logos You Need

The brand conversation before launch is about the logo, singular. What arrives afterwards is a list. A favicon at one size, a website logo, a version of it for dark backgrounds and another for light ones, a separate mobile web logo with its own two variants, app icons at whatever each platform demands, splash screens for phones, artwork for the television apps, an image for link previews when somebody shares you, and background images behind the whole thing. Every one of those has a size, most have a format, and several have a file size ceiling. Getting them wrong is not catastrophic, it is worse than that. It is invisible until a viewer sees a stretched icon on their home screen and quietly concludes your service is amateur.


Vodlix Customize Branding
The specs are on the screen

Dimensions, aspect ratio, format and maximum file size stated beside each asset, so nobody is guessing or discovering the requirement by having an upload rejected.

Vodlix Custom Themes
Light and dark variants

A logo that reads on a dark interface and disappears on a white one needs two versions. Both are asked for explicitly rather than assumed.

Vodlix Apps Management
Grouped by where they appear

Website, mobile apps, splash screens, Android icons, TV apps, link sharing and backgrounds are separate sections, because they are separate jobs done at different times.

The Dark Variant Is the One Everybody Forgets

Streaming interfaces are overwhelmingly dark, and a logo designed for a white letterhead frequently vanishes on one. The reverse is also true, which is why both variants are asked for rather than the platform attempting to invert something automatically and producing an unpleasant result. This matters beyond aesthetics because the same logo has to survive contexts you do not control, including an email client somebody has set to light mode and a link preview rendered by a social platform against whatever background it prefers. Providing both versions is a few minutes of work at setup and removes an entire category of problem later. How the surrounding colours are set is covered under themes and colours.


The Image Nobody Thinks About Until It Is Wrong

There is a section here for link sharing, and it is worth taking seriously because it governs what appears when somebody posts your service into a group chat or a social feed. That image is doing marketing work at the exact moment of highest intent, when a person is recommending you to somebody who trusts them, and the default when it is unset is usually nothing or a fragment of a page. Setting it properly costs one upload. Leaving it costs you the difference between a share that looks like a service and a share that looks like a broken link. The metadata that accompanies it is covered under content search, and the page level version under welcome landing page.


App Icons Are Where Platforms Are Least Forgiving

Website artwork is tolerant, because a browser will scale most things acceptably. App stores are not. Each platform specifies exact sizes, some require particular shapes or safe areas, and a submission with the wrong icon does not fail politely, it fails at review after you have waited for it. That is why the icons and splash screens are held here rather than being supplied per build, and it is why they carry their specifications on screen. Uploading once and having every build produced from the same set is what stops the Android app carrying an icon you replaced eight months ago. The builds themselves are covered under automated app deployment, and the wider ownership question under white label.


Frequently Asked Questions

Have questions about taking advantage of this limited-time offer? Check out the FAQ for answers.

What assets do I actually need?
More than most people expect. A favicon, website logos in light and dark variants, separate mobile web logos, app icons per platform, splash screens, television artwork, a link sharing image and background images. Each is listed with its size rather than left for you to work out.
Why do I need light and dark versions of my logo?
Because streaming interfaces are mostly dark and a logo designed for a white letterhead often disappears on one. Both are requested explicitly rather than the platform inverting something automatically and producing something unpleasant.
What happens if I skip one?
Generally a fallback is used, such as the website logo standing in for the mobile one. That is fine as a stopgap and visible as a compromise, particularly on app icons where platforms are least tolerant of the wrong dimensions.
Where does the link sharing image appear?
When somebody posts your service into a chat or a social feed. It is doing marketing at the moment of highest intent, when a person is recommending you, and unset it usually renders as nothing or a fragment of a page.
Do I have to supply these again for each app build?
No, that is the point of holding them centrally. Builds are produced from the same set, which is what prevents an app carrying an icon you replaced months earlier because a change went into one project and not the others.
Are the size requirements shown anywhere?
Beside each asset, along with the ratio, format and maximum file size. That matters most for app icons, where platforms specify exact dimensions and a submission with the wrong one fails at review rather than at upload.
Can I preview before saving?
Yes, uploaded assets are previewed before being applied, including against a transparency background so you can see whether an image you thought was cut out actually is. That catches the most common upload mistake immediately.
How is this different from white label?
White label is the proposition that the service is yours rather than ours. This is the practical work of it, which is the specific files that have to exist for that to be true on every screen a viewer might see.