Warum das TikTok-Caption-Zeichenlimit in UTF-16-Runen gemessen wird

Was ist das TikTok-Caption-Zeichenlimit?

Das dokumentierte TikTok-Caption-Zeichenlimit liegt bei 2200 UTF-16-Runen für eine Video-Caption und 90 UTF-16-Runen für den Titel eines Foto-Posts, dazu kommt ein separates Beschreibungsfeld mit 4000 Runen, das nur Foto-Posts haben. Alle drei Zahlen stammen aus TikToks Referenz zur Content Posting API, und alle drei sind in Runen statt in Zeichen angegeben. Alles Folgende beschreibt die API, denn nur dort veröffentlicht TikTok überhaupt eine Zahl.

Das Wort „caption“ ist nirgends in der API ein Feldname. Bei einem Video steht die Caption in title. Bei einem Foto-Post ist title eine kurze Überschrift, und der Caption-Text gehört in description. Dieselbe App, dieselbe Person, derselbe Vorgang des Caption-Schreibens, zwei Feldnamen, deren Limits um den Faktor vierundzwanzig auseinanderliegen.

Die dritte Zeile überrascht viele. Der Upload-Endpoint, der ein Video in den TikTok-Posteingang der Creator legt, akzeptiert überhaupt keinen Text. Sein Request-Body enthält source, video_size, chunk_size, total_chunk_count und video_url, sonst nichts. TikTok sagt Integratoren: „You should inform users that they must click on inbox notifications to continue the editing flow in TikTok and complete the post.“ Wenn dein Scheduler über diesen Endpoint postet, verlässt die Caption nie deine Datenbank.

Was ist eine UTF-16-Rune?

TikTok sagt es nicht. Die Formulierung „UTF-16 runes“ taucht in den Feldbeschreibungen auf, ohne Definition, ohne Link und ohne Beispiel, und sie verschweißt zwei Einheiten aus zwei verschiedenen Traditionen. Eine Rune ist Gos Name für einen Unicode-Codepunkt. UTF-16 ist eine Kodierung, deren Maßeinheit die Code Unit ist, und astrale Zeichen brauchen zwei davon. „UTF-16 rune“ liest sich also entweder als „code point“ oder als „UTF-16 code unit“, und das sind zwei verschiedene Zahlen.

Für einfaches Englisch sind es dieselben Zahlen. Sie gehen bei allem oberhalb von U+FFFF auseinander, und dort leben sämtliche piktografischen Emoji.

Nicht-lateinische Schriften sind nicht das Problem, für das man sie hält. Japanische Kana liegen in der Basic Multilingual Plane, fünf Kana kosten also unter beiden Lesarten fünf. Doppelt kostet alles, was oberhalb von U+FFFF kodiert ist: Emoji, historische Schriften, einige CJK-Erweiterungsblöcke, mathematische alphanumerische Zeichen.

Ich lese die Mehrdeutigkeit als Hinweis auf Code Units, denn das ist die Zahl, die ein Server umsonst bekommt: String.prototype.length in JavaScript und String.length() in Java liefern beide Code Units. Das ist eine Vermutung über TikToks Implementierung und keine Aussage von TikTok, behandle 2200 und 90 also als Obergrenzen, unter denen du bleibst, nicht als Zielwerte, die du triffst.

Wie viel kostet ein einzelnes Emoji im Limit?

Zwischen 1 und 11, und der Lesende sieht so oder so eine einzige Glyphe. Die Kosten sind unter der einen Lesart die Zahl der Codepunkte im Emoji und unter der anderen die Summe ihrer UTF-16-Breiten. Jeder Codepunkt oberhalb von U+FFFF ist 2 Code Units breit. Zero Width Joiner und Variantenselektoren sind je 1.

Das Torii-Tor ist der Sonderfall. Es ist ein BMP-Symbol mit einem Variantenselektor, beide Lesarten kommen also auf 2, während der Lesende 1 sieht. Das Familien-Emoji ist mit 11 Code Units das teuerste, und auf einem Foto-Titel mit 90 Runen ist das mehr als ein Zehntel des Feldes.

Ein Foto-Titel, der eine Lesart besteht und an der anderen scheitert

Nimm diesen Titel für einen Foto-Post: Autumn in Kyoto: the twelve quiet corners we walked before dawn, day 1 🍁🍂🏯🌄👘🎋⛩️👩‍👩‍👧‍👦. Er besteht aus 71 ASCII-Zeichen und acht Emoji. Wer ihn liest, zählt 79 Dinge, bequem innerhalb von 90.

Liest man „UTF-16 runes“ als Codepunkte, ist der Titel 86 lang und passt. Liest man es als UTF-16 Code Units, sind es 96 und er passt nicht. Ein String, ein dokumentiertes Limit von 90, zwei vertretbare Lesarten, gegensätzliche Antworten. Tausche das Familien-Emoji gegen 👪 U+1F46A, und derselbe Titel fällt unter der strengen Lesart auf 87 und wird unter beiden veröffentlicht.

Warum scheitert dieselbe Caption an einem Foto-Post?

Weil eine Video-Caption 2200 Runen zur Verfügung hat und ein Foto-Titel 90. Ein Tool, das eine Caption pro geplantem Post speichert und sie auf beiden Endpoints auf title abbildet, ist beim Video in Ordnung und beim Foto 24-mal über dem Budget. Entweder kürzt es den String vor dem Senden und wirft den Großteil der Caption ohne Warnung weg, oder TikTok lehnt den Aufruf ab.

Wenn TikTok ablehnt, ist die Antwort nicht spezifisch. Keine der beiden Referenzen veröffentlicht einen benannten Fehler für eine zu lange Caption. Der Auffangfall ist invalid_param mit HTTP 400, beschrieben als „Check error message for details“, und die übrigen dokumentierten Codes decken anderes ab: spam_risk_too_many_posts, reached_active_user_cap, url_ownership_unverified, privacy_level_option_mismatch, scope_not_authorized, rate_limit_exceeded. Die Längenprüfung muss in deinem Code passieren, denn die API sagt dir nicht, welches Feld zu lang war.

Das richtige Mapping behandelt Foto-Posts als zwei Felder statt als eines. Halte die Überschrift in title kurz und leg den Caption-Text in description, das mit 4000 Runen das geräumigste Textfeld der gesamten Content Posting API ist. Das Feld namens description bei einem Foto-Post fasst fast doppelt so viel wie das Feld namens title bei einem Video. Die Namen stehen im Verhältnis zu den Größen verkehrt herum.

Hashtags sind eine zweite Asymmetrie. TikTok dokumentiert das Parsing nur für das Video-Feld, in einem Satz, der mit einem Tippfehler ausgeliefert wird: „Hashtags (#) and mentions (@) will be matched, or deliminated by spaces or new lines.“ In der Foto-Referenz steht für keines der beiden Felder ein entsprechender Satz. Ob ein #tag, das in eine Foto-Description getippt wird, zu einem echten Tag wird, ist undokumentiert, teste es also zuerst an einem SELF_ONLY-Post.

Wie zählst du eine TikTok-Caption, bevor du sie sendest?

Berechne alle drei Zahlen und validiere gegen die größte. Intl.Segmenter liefert dir die Zählung des Lesenden in Node und im Browser ohne zusätzliche Abhängigkeit, die anderen beiden sind eingebaut.

const segmenter = new Intl.Segmenter('en', { granularity: 'grapheme' });
 
const readings = (text) => ({
  reader: [...segmenter.segment(text)].length,
  codePoints: [...text].length,
  utf16Units: text.length,
});
 
const LIMITS = { videoTitle: 2200, photoTitle: 90, photoDescription: 4000 };
 
const fits = (text, field) => readings(text).utf16Units <= LIMITS[field];

text.length ist die strenge Lesart, eine Validierung dagegen hält dich unter beiden Interpretationen auf der sicheren Seite. Greif hier nicht zu Buffer.byteLength(text, 'utf8'). UTF-8-Bytes sind eine dritte Einheit, die 3 pro Kana und 4 pro astralem Emoji berechnet, und nichts in TikToks Dokumentation verlangt danach. Diese Regel gehört zu Threads. Die beiden zu verwechseln, lehnt Captions ab, die TikTok akzeptiert hätte.

Ist das In-App-Caption-Limit dasselbe wie das API-Limit?

TikTok veröffentlicht keine In-App-Zahl, es gibt also nichts zu vergleichen. Die Referenz zur Content Posting API nennt 2200, 90 und 4000 für die drei API-Felder und sagt nichts über den Composer in der App. Die Hilfe-Center-Artikel, die das abdecken würden, liegen unter URLs, die ich nicht erreichen konnte. Zahlen, die für den In-App-Composer kursieren, gehen auf Marketing-Beiträge zurück und nicht auf TikTok, ich wiederhole sie deshalb nicht.

Behandle beides als getrennt, bis TikTok es anders dokumentiert. Eine in der App getippte Caption und eine über /v2/post/publish/video/init/ gesendete Caption nehmen unterschiedliche Wege, und nur einer davon hat eine veröffentlichte Zahl.

Eine weitere Einschränkung ist dokumentiert, auf einer anderen Seite. TikToks Richtlinien zum Content-Sharing verlangen, dass „API Clients must allow users to enter or select the following metadata for a post: a. Title“, und dass „Preset text, including any text in the title field or hashtags, should be allowed to be edited by the user before posting content.“ Ein Tool, das eine Caption generiert und ohne Möglichkeit zur Bearbeitung postet, ist nicht konform, egal wie viele Runen es verbraucht hat.

Wo adaptlypost hineinpasst

adaptlypost postet über dieselbe Content Posting API zu TikTok, 2200, 90 und 4000 gelten für einen geplanten Post also genauso wie für einen von Hand getippten. Plattformlimits gehören TikTok. Was sich durch Planung ändert, ist der Zeitpunkt, an dem du davon erfährst, denn eine in einem Content-Kalender entworfene Caption lässt sich Tage vor dem Sendezeitpunkt messen statt erst in dem Moment, in dem die API invalid_param zurückgibt.

Der Widerspruch wird schärfer, sobald ein Entwurf an mehrere Netzwerke geht, was beim Multi-Plattform-Posting der Normalfall ist. Jedes Netzwerk definiert seine eigene Zähleinheit, eine für ein Netzwerk dimensionierte Caption ist auf dem nächsten also nicht automatisch sicher. Wenn du mit dem KI-Caption-Writer schreibst, ist die nützliche Gewohnheit, die Emoji ans Ende zu setzen, wo ihr Wegkürzen dich nichts kostet.

Zur Planung siehe den TikTok-Post-Scheduler. Zu den Endpoints siehe TikTok Posting API, und dazu, was die Posts danach gemacht haben, TikTok Analytics.

Häufig gestellte Fragen

Was ist die maximale TikTok-Caption-Länge in der API?

2200 UTF-16-Runen für eine Video-Caption, die TikToks Referenz zur Content Posting API im Feld title von /v2/post/publish/video/init/ verortet. Foto-Posts sind anders: title ist auf 90 UTF-16-Runen begrenzt und description auf 4000, beide auf /v2/post/publish/content/init/.

Was meint TikTok mit UTF-16-Runen?

TikTok definiert den Begriff nicht. Eine Rune ist Gos Wort für einen Unicode-Codepunkt, während UTF-16 in Code Units misst, und die beiden Lesarten unterscheiden sich bei jedem Zeichen oberhalb von U+FFFF. Validiere gegen die Zahl der Code Units, in JavaScript text.length, denn sie ist die größere der beiden und hält dich unter beiden Lesarten innerhalb des Limits.

Warum liegt das TikTok-Foto-Caption-Limit bei nur 90 Zeichen?

Die Grenze von 90 Runen gilt für title, und das ist bei Foto-Posts ein Überschriftenfeld und nicht die Caption. Der Caption-Text gehört in description, das 4000 UTF-16-Runen erlaubt. Ein Tool, das eine gespeicherte Caption auf beiden Endpoints auf title abbildet, stößt an die 90 und kann nichts anderes tun als kürzen.

Wie viele Zeichen verbraucht ein Emoji in einer TikTok-Caption?

Zwischen 1 und 11, je nachdem wie es aufgebaut ist. Ein Emoji aus einem einzigen Codepunkt wie 😀 kostet 1 als Codepunkt und 2 als UTF-16 Code Units. Das vierköpfige Familien-Emoji 👩‍👩‍👧‍👦 besteht aus sieben Codepunkten, die von Zero Width Joinern zusammengeschweißt werden, also 7 oder 11 je nach Lesart, für etwas, das der Lesende als eine Glyphe sieht.

Welchen Fehler gibt TikTok zurück, wenn eine Caption zu lang ist?

TikTok veröffentlicht keinen benannten Fehler für eine zu lange Caption. Der Auffangfall ist invalid_param mit HTTP 400, dokumentiert als „Check error message for details“, und die übrigen veröffentlichten Codes decken Spam-Risiko, Kontingente, unbestätigte URL-Eigentümerschaft, Privacy-Mismatch und Autorisierung ab. Prüf die Länge selbst, bevor du den Endpoint aufrufst.

Ist das TikTok-In-App-Caption-Limit dasselbe wie das API-Limit?

TikTok veröffentlicht keine Zahl für den Composer in der App, aus der Dokumentation lassen sich die beiden also nicht vergleichen. Die Werte 2200, 90 und 4000 gelten laut Referenz zur Content Posting API ausschließlich für API-Felder. Jede In-App-Zahl, die du anderswo findest, stammt nicht von TikTok.

Kannst du beim Posten eines TikTok-Videos in die Entwürfe eine Caption hinzufügen?

Der Endpunkt, der ein Video in den TikTok-Posteingang eines Creators stellt, /v2/post/publish/inbox/video/init/, hat überhaupt kein Caption-Feld. Sein Request-Body nimmt nur source, video_size, chunk_size, total_chunk_count und video_url entgegen. TikTok erwartet, dass der Creator die Caption erst in der App hinzufügt, nachdem er auf die Posteingang-Benachrichtigung getippt hat, denn eine Caption aus deinem Scheduler erreicht diesen Endpunkt nie.

Parst TikTok Hashtags bei einem Foto-Post genauso wie bei einem Video?

TikTok dokumentiert das Parsen von Hashtags und Erwähnungen nur für das title-Feld beim Video, in einem Satz, der sie als "matched, or deliminated by spaces or new lines" beschreibt. Für die Foto-Referenz gibt es keinen entsprechenden Satz, weder für title noch für description. Ob ein #tag in einer Foto-Caption zu einem echten Tag wird, ist nicht dokumentiert, also teste es zuerst an einem SELF_ONLY-Post.

Darf ein Scheduling-Tool eine TikTok-Caption posten, ohne dass du sie vorher bearbeiten kannst?

TikToks Richtlinien zum Content-Sharing schließen das aus. Sie verlangen, dass API-Clients Nutzern erlauben, einen Titel einzugeben oder auszuwählen, und dass voreingestellter Text im Titel-Feld oder in Hashtags vor dem Posten bearbeitbar sein muss. Ein Tool, das eine Caption generiert und ohne Bearbeitungsmöglichkeit postet, verstößt dagegen, egal wie viele Runen es verbraucht hat.

Solltest du eine TikTok-Caption in UTF-8-Bytes zählen?

UTF-8-Bytes sind die falsche Einheit für TikTok. TikToks dokumentierte Limits stehen in UTF-16-Runen, nicht in Bytes, und UTF-8 berechnet 3 Bytes pro Kana-Zeichen und 4 pro Emoji oberhalb der BMP, Zahlen, die TikToks Dokumentation nirgends verlangt. Diese Byte-Regel gehört zu Threads; wer beides vermischt, lehnt Captions ab, die TikTok akzeptiert hätte.