What Playable_orientation actually does
TikTok's playable spec requires a first-level config.json alongside index.html, and that file has to declare Playable_orientation. Functionally, it plays the same role as an orientation meta tag in a Google Ads playable — it tells the ad server how to size and lock the viewport the creative will render inside, before the HTML itself ever loads. The difference is delivery mechanism, not purpose: Google reads an HTML <meta> tag baked into the entry file itself, while TikTok reads a JSON field in a separate manifest that sits next to index.html. Both exist so the ad server can pick the right frame for the creative without having to parse and execute the playable first.
That ordering matters. Because TikTok's review pipeline reads config.json before anything renders, a wrong or missing orientation value is a packaging-level problem, not a rendering bug you'd catch by opening the ZIP's HTML in a browser. The playable can run perfectly in a local preview and still be flagged in review, because the manifest — not the page — is what TikTok's server trusts first.
What values does it accept?
Playable_orientation is a number, not a string, and PlayableKit's own generator (which writes this field automatically during conversion) maps it as follows:
| Value | Meaning |
|---|---|
1 | Portrait-only |
2 | Landscape-only |
0 | Both orientations / unspecified |
- The value has to describe one real orientation — the one your creative is actually built and locked to, not a placeholder or a value copied from a template for a different network's spec.
- It's numeric, not a quoted string.
"Playable_orientation": 1is correct;"Playable_orientation": "1"or"portrait"is a type mismatch that can pass a naive JSON-validity check while still failing TikTok's actual parsing. - When in doubt, confirm against TikTok's current official playable-ads documentation before resubmitting — ad network specs get revised, and this mapping reflects what PlayableKit generates today, not a guarantee TikTok will never change the convention.
- Test before you submit. Since a bad value doesn't break local rendering, the only reliable check is running the packaged ZIP through a validator or TikTok's own review flow rather than trusting a browser preview.
Common mistakes with this field
| Mistake | Why it happens |
|---|---|
Field missing even though config.json exists | The manifest was created to satisfy the "config.json must be present" check, but Playable_orientation itself was never added — the file exists and is technically valid JSON, it's just incomplete. |
| Value doesn't match how the creative actually renders | The build was re-oriented at some point (locked to landscape instead of portrait, or vice versa) but the manifest value was never updated to match, so the declared orientation and the real layout disagree. |
| Wrong data type | The value is written as a number where a string is expected (or the reverse), or wrapped in the wrong casing/quoting — a subtly malformed field that parses as JSON but doesn't match what TikTok's pipeline is looking for. |
| Copy-pasted from a different network's config | Teams shipping to multiple networks sometimes carry over a manifest field from an unrelated build step, landing on a value that was never actually meant for this creative. |
The fix
Open config.json at the first level of your ZIP and confirm three things in order: the file is present, Playable_orientation exists as a key inside it, and the value matches the orientation your creative is genuinely locked to — not the orientation you intended early in development, and not a value borrowed from another network's packaging step. If you're not certain which exact string TikTok expects for a given orientation, don't guess: pull the value from a playable of yours that has already cleared TikTok review, or confirm against TikTok's current official spec before resubmitting.
For the general case of a full TikTok package — entry file placement, SDK, CTA wiring, and the rest of the manifest requirements alongside orientation — the TikTok playable ads reference covers the whole spec. And if config.json isn't in the ZIP at all rather than just having a wrong field, that's the narrower missing config.json case, not this one.
Playable_orientation value doesn't show up when you open the creative locally — the HTML runs fine either way. It only surfaces once TikTok's review pipeline parses the manifest, which is exactly the kind of packaging issue PlayableKit's Playable Ad Validator flags before you submit, at no cost and with no signup.