Limiti di caratteri e parole 2026 — Twitter, SMS, SEO, Instagram

Un limite di caratteri è il numero massimo di punti di codice (codepoint) Unicode che una piattaforma accetta in un singolo campo: 280 per un post su Twitter, 160 per un SMS a segmento singolo in GSM-7, circa 160 per una meta description di Google prima del troncamento. Il numero che ti interessa dipende da dove pubblichi e dal fatto che il tuo testo contenga emoji, virgolette tipografiche o caratteri CJK, perché tutti questi elementi cambiano la matematica.

Questa guida è pensata per chi scrive sui social media, specialisti SEO, copywriter di marketing, mittenti SMS fatturati a segmento e sviluppatori che scrivono validazioni allineate a ciò che Twitter, Instagram o i gateway SMS contano davvero. Salta alla tabella di riferimento rapido per il cheat sheet su 25 piattaforme, oppure verifica la tua bozza in tempo reale contro sei piattaforme principali con il Contatore di parole: le barre di avanzamento diventano rosse nel momento esatto in cui superi un limite.

Tabella di riferimento rapido — Limiti di caratteri e parole per ogni piattaforma

La tabella qui sotto copre più di 30 campi in cui scrittori e sviluppatori si imbattono più spesso. “Limite assoluto” è il tetto imposto dalla piattaforma; “Visibile / sopra la piega” è ciò che i lettori vedono prima del punto di troncamento; “Zona ottimale” è l’intervallo empirico in cui il contenuto rende meglio.

Piattaforma	Limite assoluto	Visibile / sopra la piega	Zona ottimale	Conteggio emoji
Post Twitter / X	280 caratteri	280	70-100 caratteri	1 codepoint
Bio Twitter / X	160 caratteri	160	—	1 codepoint
Nome visualizzato Twitter / X	50 caratteri	50	—	1 codepoint
X Premium long-form	25.000 caratteri	—	—	1 codepoint
Didascalia Instagram	2.200 caratteri	primi 125 (poi “altro”)	<125 per l’hook	1 codepoint
Bio Instagram	150 caratteri	150	—	1 codepoint
Hashtag Instagram	max 30	—	5-10	—
Post LinkedIn	3.000 caratteri	primi 210 (poi “vedi altro”)	<1.300	1 codepoint
Articolo LinkedIn	110.000 caratteri	—	—	1 codepoint
Headline LinkedIn	220 caratteri	220	—	1 codepoint
Post Facebook	63.206 caratteri	~477 desktop / ~125 mobile	<80 per la portata organica	1 codepoint
Didascalia TikTok	2.200 caratteri	primi ~100	<150	1 codepoint
Titolo YouTube	100 caratteri	70 (ricerca)	<60	1 codepoint
Descrizione YouTube	5.000 caratteri	primi 100-150 sopra la piega	primi 150 per l’hook	1 codepoint
Commento YouTube	10.000 caratteri	—	—	1 codepoint
Titolo Reddit	300 caratteri	—	<60 (dipende dal subreddit)	1 codepoint
Commento Reddit	10.000 caratteri	—	—	1 codepoint
Messaggio Discord	2.000 caratteri	2.000	—	1 codepoint
Descrizione embed Discord	4.096 caratteri	—	—	1 codepoint
Messaggio Slack	40.000 caratteri	—	<2.000 per leggibilità	1 codepoint
Descrizione pin Pinterest	500 caratteri	primi 50-60	<125	1 codepoint
Toot Mastodon	500 caratteri (configurabile)	500	—	1 codepoint
Post Bluesky	300 caratteri	300	—	1 grapheme cluster
Post Threads	500 caratteri	500	—	1 codepoint
Meta description SEO (Google)	~160 caratteri desktop / ~120 mobile	150-160	150-160	1 codepoint
Title tag SEO (Google)	~60 caratteri desktop / ~50 mobile	50-60	50-60	1 codepoint
Descrizione Open Graph	~200 caratteri prima del clip LinkedIn/FB	150-200	150-200	1 codepoint
Descrizione Twitter Card	200 caratteri max	200	150-200	1 codepoint
SMS segmento singolo (GSM-7)	160 caratteri	—	—	speciale — vedi sotto
SMS segmento singolo (UCS-2 / emoji)	70 caratteri	—	—	1 codepoint
Testo messaggio WhatsApp	65.536 caratteri	—	—	1 codepoint
Oggetto email	nessun limite di piattaforma	~60 desktop / ~30 mobile	<50	1 codepoint
Headline Google Ads	30 caratteri × 15 headline	30 ciascuno	30	1 codepoint
Descrizione Google Ads	90 caratteri × 4 descrizioni	90 ciascuno	90	1 codepoint
Titolo App Store	30 caratteri	30	30	1 codepoint
Sottotitolo App Store	30 caratteri	30	30	1 codepoint
Descrizione App Store	4.000 caratteri	primi 252 sopra la piega	hook a 252	1 codepoint
Descrizione breve Play Store	80 caratteri	80	80	1 codepoint
Descrizione lunga Play Store	4.000 caratteri	primi 80 sopra la piega	hook a 80	1 codepoint

I contenuti sopra la soglia della “zona ottimale” tendono a essere troncati, retrocessi nel ranking o tagliati fuori dalla card visibile. X Premium long-form e Mastodon (configurabile per istanza) sono le rare eccezioni che ti permettono di scrivere oltre i 500 caratteri senza penalità. Ogni conteggio sopra, tranne dove valgono le regole SMS, è un conteggio di punti di codice Unicode: un emoji costa 1 carattere, non 2. Per verificare una bozza contro i sei limiti più comuni in un colpo solo, incollala nel Contatore di parole; le barre di avanzamento intercettano il testo fuori limite prima che tu premi pubblica.

Come si contano davvero i caratteri (punti di codice Unicode vs UTF-16)

Tre strumenti diversi possono restituirti tre conteggi diversi per la stessa stringa. La ragione è che “carattere” non è una cosa sola: può significare un punto di codice Unicode, una unità di codice (code unit) UTF-16, o un cluster di grafemi (grapheme cluster), e ogni piattaforma sceglie una di queste.

Cos’è un “carattere” — codepoint vs code unit vs grafema

Un codepoint è un valore scalare Unicode: qualunque intero da U+0000 a U+10FFFF che Unicode abbia assegnato a un carattere o riservato. Una code unit è il pezzo più piccolo di una codifica; UTF-16 usa code unit a 16 bit, UTF-8 usa code unit a 8 bit. Un grapheme cluster è ciò che gli esseri umani percepiscono come un singolo carattere visibile: a volte un solo codepoint, a volte un codepoint base più segni combinanti, a volte una sequenza zero-width-joiner come l’emoji famiglia 👨‍👩‍👧‍👦 (sette codepoint uniti in un unico glifo visibile).

Per la stringa "a🌍👨‍👩‍👧" i tre conteggi non coincidono:

Metodo di conteggio	Risultato	Usato da
Code unit UTF-16 (JS `string.length`)	10	Codice JavaScript ingenuo
Punti di codice Unicode	6	Twitter, Instagram, gateway SMS
Grapheme cluster	3	Bluesky, screen reader, editor di testo

Perché `string.length` mente sugli emoji

JavaScript memorizza internamente le stringhe come UTF-16. Qualunque codepoint sopra U+FFFF (ogni emoji, tutti i caratteri del piano astrale) viene codificato come una coppia surrogata (surrogate pair) di due code unit a 16 bit. La proprietà .length riporta quelle due unità, non un carattere.

"🌍".length              // 2   (UTF-16 code units)
[..."🌍"].length         // 1   (codepoints — what Twitter/SMS counts)
"🌍".match(/./gu).length // 1   (codepoints via regex with /u flag)

L’operatore spread e il flag regex /u iterano entrambi per codepoint, in linea con ciò che Twitter, Instagram e i gateway SMS misurano rispetto ai loro limiti. Una funzione di validazione che usa .length grezzo rifiuterà tweet che in realtà rientrano nel limite oppure, peggio ancora, lascerà passare messaggi che il sistema a valle rifiuterà.

E i caratteri CJK e i segni combinanti?

Gli ideogrammi cinesi, giapponesi e coreani sono ciascuno un singolo codepoint e contano come un carattere su ogni piattaforma. Diventano costosi negli SMS: qualsiasi carattere non-GSM-7 ribalta l’intero messaggio in codifica UCS-2, facendo scendere il limite di segmento da 160 a 70 (lo vediamo nella prossima sezione).

I segni combinanti si comportano diversamente. La á accentata scritta come á è un codepoint; la stessa á scritta come a + ́ (accento acuto combinante) è due codepoint ma un solo grapheme cluster. La maggior parte delle piattaforme conta per codepoint, quindi la seconda forma costa un carattere in più. Bluesky è l’eccezione visibile: conta i grapheme cluster, quindi entrambe le forme costano 1.

Contare in linguaggi diversi — riferimento rapido

// JavaScript
[...str].length                          // codepoints
Array.from(str).length                   // codepoints

// Python 3 — len() is codepoint by default
len(s)

// Go — utf8 package
utf8.RuneCountInString(s)

// Rust — chars() iterates codepoints
s.chars().count()

// Java — codePointCount
s.codePointCount(0, s.length())

Per confronto, il Codificatore e decodificatore Base64 ti ricorda l’altro verso del problema: quando il testo viene codificato in Base64 per la trasmissione, ogni 3 byte di input UTF-8 diventano 4 caratteri ASCII in output, quindi la lunghezza codificata dipende dal conteggio byte, non dal conteggio codepoint. Incolla un singolo emoji e guarda l’output Base64 espandersi a 8 caratteri: lo stesso emoji che costa 1 carattere su Twitter occupa 4 byte in UTF-8.

Per vedere il conteggio dei codepoint (il numero che Twitter misura davvero) su una qualsiasi bozza, il Contatore di parole è Unicode-corretto di default.

Limite caratteri SMS — GSM-7, UCS-2 e messaggi multi-parte

Gli SMS sono l’unico canale principale dove aggiungere un singolo emoji può letteralmente raddoppiare la tua bolletta. La ragione è la codifica e la matematica è la stessa dal 1985.

Il numero magico 160 — la storia di GSM-7

Lo standard GSM-03.38 del 1985 ha fissato il payload di un SMS a 140 byte. Con una codifica di caratteri a 7 bit, 140 byte contengono 1.120 bit ÷ 7 = 160 caratteri. Da qui nasce il famoso limite caratteri SMS di 160. Il set di caratteri GSM-7 copre 128 caratteri base più un’estensione di 10 caratteri (che include { } [ ] | \ ~ ^ € e form feed). Dentro quel set hai il budget pieno di 160 caratteri per segmento.

I caratteri che cadono fuori da GSM-7 e forzano il passaggio:

Tutti gli emoji
Virgolette tipografiche / “smart” (" " ' '); attenzione, sono diverse dalle virgolette ASCII dritte " '
La maggior parte delle lettere latine accentate oltre alle 35 in GSM-7 (é á ñ ü ø ecc.; GSM-7 include solo ä ö å æ ø à è ì ò ù e poche altre)
Punteggiatura a larghezza piena, caratteri CJK, arabo, ebraico, greco minuscolo, cirillico
Backtick ` e tilde ~ (la tilde è nella tabella di estensione GSM-7, quindi costa 2 dei tuoi 160 caratteri)

La trappola UCS-2 — un emoji ti porta da 160 a 70

Nel momento in cui un singolo carattere non-GSM-7 compare ovunque nel messaggio, l’intero messaggio passa alla codifica UCS-2. UCS-2 usa 16 bit per carattere, quindi 140 byte ÷ 2 = 70 caratteri per segmento. Esempi reali:

"Hello, your code is 12345"            → 26 chars, GSM-7, 1 segment
"Hello, your code is 12345 ✓"          → 28 chars, GSM-7 (✓ in extension), 1 segment
"Hello, your code is 12345 ✅"          → 28 chars, UCS-2 (emoji), 1 segment (under 70)
"Hello, "your" code is 12345 ✅"        → smart quotes + emoji → UCS-2
"Hi 你好"                                → CJK → UCS-2, 1 segment (5 chars)

Quell’ultimo esempio “Hi 你好” è il tranello: sono solo 5 caratteri ma scatta il prezzo UCS-2 e i successivi 65 caratteri che aggiungi entreranno in un solo segmento, poi parte il segmento 2.

SMS multi-parte (concatenazione)

Una volta superati i 160 (GSM-7) o i 70 (UCS-2), il messaggio si divide in più segmenti. Ogni segmento porta un User Data Header (UDH) di 7 caratteri usato per il riassemblaggio, quindi il payload disponibile per segmento cala:

GSM-7 multi-parte: 153 caratteri per segmento
UCS-2 multi-parte: 67 caratteri per segmento

Il telefono ricevente riassembla i segmenti in modo invisibile al destinatario, ma la fatturazione è per segmento, non per messaggio. Un messaggio GSM-7 da 161 caratteri costa 2 segmenti. Un messaggio GSM-7 da 1.000 caratteri costa 7 segmenti (153 × 6 = 918, il 7° segmento porta gli ultimi 82).

La matematica del costo — quando un emoji raddoppia la bolletta

Considera un messaggio di marketing in testo semplice da 80 caratteri:

Testo semplice: 80 caratteri → GSM-7 → 1 segmento al prezzo X
Aggiungi un emoji: 80 caratteri → UCS-2 → 80 > 70 → 2 segmenti al prezzo 2X

Raddoppiare la bolletta con un emoji è reale e scala. Una campagna da 100.000 messaggi a 0.0075 $ per segmento costa 750 $ in GSM-7 contro 1.500 $ in UCS-2: un emoji da 750 $. Ogni grande provider SMS (Twilio, Bandwidth, AWS SNS, MessageBird, Vonage) fattura in questo modo. Le regole di codifica sono standard GSM, non policy del vendor. La storia approfondita dei trade-off di codifica a livello byte (e perché ASCII, UTF-8, UCS-2 esistono come standard separati) è coperta in Capire Base64, che è la stessa famiglia di problemi “bit dentro caratteri” applicata all’email invece che agli SMS.

Come mantenere i messaggi in GSM-7

Usa virgolette ASCII dritte " ', non virgolette tipografiche
Usa il trattino ASCII -, non em-dash — o en-dash –
Scrivi per esteso (c) e (R), non © e ®
Evita gli emoji a meno che il budget della campagna non assuma il costo UCS-2
Le console dei provider (di Twilio, Bandwidth, MessageBird) mostrano “encoding: GSM-7” o “UCS-2” accanto all’anteprima; verifica prima del broadcast

Il controllo di sanità più rapido durante la stesura è la barra di avanzamento SMS del Contatore di parole, che riporta rispetto alla baseline di 160 caratteri. Se il tuo testo innesca UCS-2, dividi mentalmente il conteggio caratteri per 2.29 per stimare il numero di segmenti sotto la regola dei 70 caratteri.

Limiti SEO — meta description, title tag, OG, Twitter Card

I limiti di caratteri SEO sono più morbidi di quelli delle piattaforme (Google non rifiuterà la tua pagina se una meta description tocca i 300 caratteri), ma le regole pratiche di troncamento contano per il click-through rate. Ecco i numeri che reggono ancora nel 2026.

Meta description — zona ottimale 150-160 caratteri

I risultati di ricerca desktop di Google troncano la meta description intorno ai 155-165 caratteri; il mobile taglia da qualche parte tra 100 e 120. Il punto esatto di troncamento varia perché Google misura i pixel di visualizzazione, non i caratteri. Una descrizione piena di glifi W e M raggiunge il pixel di troncamento prima di una piena di i e l.

Regole pratiche di scrittura:

Punta a 150-160 caratteri totali
Metti il messaggio centrale nei primi 120 caratteri (sicuro su mobile)
Apri con la keyword limite di caratteri meta description della pagina nei primi 30 caratteri
Chiudi con una CTA negli ultimi 30 caratteri, leggibile anche quando desktop taglia il centro

L’era 2017-2018 ha visto Google espandere brevemente la visualizzazione della meta description a 320 caratteri, e una generazione di tutorial SEO cita ancora quel numero. Google è tornata a 160 a metà 2018. Scrivere oltre i 200 caratteri oggi nasconde solo la seconda metà.

Una modalità di fallimento diversa: le descrizioni sotto i 120 caratteri vengono spesso sostituite del tutto. Google decide che la tua descrizione non serve pienamente la query e tira fuori un passaggio diverso dal corpo della pagina, e perdi il controllo del CTR senza preavviso.

Title tag — 60 desktop, 50 mobile

I title tag vengono tagliati intorno ai 60 caratteri su desktop e 50 su mobile. Stesso troncamento basato sui pixel delle descrizioni, stessa avvertenza sui glifi larghi.

Zona ottimale: 50-60 caratteri, con la keyword target nei primi 30 in modo che sopravviva a qualunque taglio. I suffissi long-tail di brand (| Brand Name) stanno alla fine, dove il troncamento fa meno male.

Larghezza in pixel vs conteggio caratteri: la regola reale di Google

Il contenitore della descrizione nella SERP di Google è largo circa 920 pixel su desktop. La larghezza media dei caratteri si attesta intorno ai 6.5 pixel, da cui il target empirico di 140-160 caratteri. Ma lo spread per carattere è ampio: i rende a circa 3 pixel, M a circa 11. Una descrizione tutta maiuscola (“BEST WIDGETS FOR WINTER WEDDINGS”) viene tagliata sostanzialmente prima rispetto all’equivalente minuscolo.

Le anteprime pre-pubblicazione che usano simulatori SERP pixel-accurati sono più affidabili dei contatori di caratteri per il copy SEO.

Descrizione OG e descrizione Twitter Card

L’og:description del protocollo Open Graph è ciò che Facebook, LinkedIn, Slack e Discord renderizzano sotto l’anteprima di un link condiviso. I tetti di visualizzazione variano per piattaforma: la maggior parte taglia intorno ai 200 caratteri, alcune si estendono a 300. La twitter:description della Twitter Card è limitata in modo rigido a 200 caratteri nel parser di Twitter.

Default sensati:

150-200 caratteri sia per OG sia per Twitter Card
Possono coincidere con la tua meta description, ma OG può essere leggermente più lunga perché la lunghezza OG non influisce sul ranking di ricerca
Convalida le scelte sui dati strutturati (specialmente cosa viene tirato in OG per errore) usando i pattern in Buone pratiche di sicurezza, dove metadati OG non attendibili sono un vettore comune di phishing

Cosa significa davvero “nessun limite di caratteri”

I tag H1, il corpo del contenuto e gli slug URL non hanno un limite di caratteri SEO imposto dalla piattaforma, ma valgono ancora limiti soft:

H1 > 70 caratteri rompe la gerarchia visiva e la scansionabilità
Slug URL tecnicamente illimitati; Google ne mostra circa 90 caratteri nella SERP, oltre è solo cosmetico
Il corpo non ha tetto di lunghezza, ma Google premia il contenuto utile sul riempitivo, e il word count da solo non è un segnale di ranking

Il Contatore di parole traccia sia la meta description (160) sia il title tag (60) dal vivo mentre scrivi, con barre di avanzamento che diventano ambra e rosse mentre ti avvicini al pixel di troncamento.

Ogni tetto di caratteri di una piattaforma ha una storia dietro e una zona ottimale sotto il limite assoluto in cui il contenuto rende davvero.

Twitter / X — 280, premium 25.000, regola di sostituzione URL

Il limite caratteri Twitter standard è di 280 caratteri, raddoppiato dai 140 nel novembre 2017. Gli abbonati a X Premium possono pubblicare contenuti long-form fino a 25.000 caratteri con formattazione ricca, ma il post da 280 caratteri resta la forma dominante per la portata organica.

La regola meno ovvia è la sostituzione URL. Twitter avvolge ogni URL, indipendentemente dalla sua lunghezza, in uno short link t.co da 23 caratteri al momento della pubblicazione. Il costo da 23 caratteri è fisso.

published_length = raw_length − URL_length + 23

Esempio: una bozza come "Check this: https://example.com/very-long-path?id=12345" è 53 caratteri grezzi. L’URL è 38 caratteri, quindi viene sostituito con un link t.co da 23 caratteri, e la lunghezza pubblicata è 53 − 38 + 23 = 38 caratteri. Risparmi 15 caratteri che non sapevi di avere.

Per incollare un URL lungo in una bozza, il Codificatore e Decodificatore URL è un modo rapido per verificare cosa conta come URL (Twitter riconosce gli URL tramite i pattern RFC 3986, query string e fragment inclusi). Sottodomini, schemi, porte, path, query e fragment vengono tutti inghiottiti dalla sostituzione da 23 caratteri.

Altri campi Twitter: nome visualizzato 50 caratteri, bio 160 caratteri, handle 15 caratteri. Threads (l’equivalente Twitter di Meta) usa invece un limite di 500 caratteri.

Instagram — didascalia 2.200, 30 hashtag, hook da 125 caratteri

Le didascalie Instagram permettono 2.200 caratteri, ma il feed mostra solo i primi 125 caratteri prima di collassare il resto dietro a un tap su ”… altro”. Più della metà dei lettori non tappa mai. Il limite didascalia Instagram che conta per l’engagement è quindi 125, anche se il limite assoluto è 2.200.

Il tetto di 30 hashtag è rigido: provare a inserire un 31° hashtag fa fallire il post. L’intervallo 5-10 hashtag tende a rendere meglio; oltre gli 11 il boost di discovery si appiattisce e il post inizia a sembrare spam all’algoritmo.

Altri campi: bio 150 caratteri, nome visualizzato 30 caratteri, DM 1.000 caratteri.

LinkedIn — post 3.000, zona ottimale 1.300, soglia “vedi altro”

Il limite caratteri LinkedIn per i post è 3.000, ma il feed mostra solo i primi 210 caratteri prima della soglia “vedi altro”. I post nella fascia 1.200-1.500 caratteri vincono in engagement su LinkedIn (studi multipli di Buffer e Hootsuite convergono intorno a 1.300 come picco); sono abbastanza lunghi da dimostrare valore, abbastanza brevi da non logorare lo scroll.

Gli articoli LinkedIn (la superficie di pubblicazione long-form) permettono 110.000 caratteri, di fatto illimitati. Le headline del profilo si fermano a 220, la sezione about a 2.600.

Facebook — 63.206 caratteri, zona ottimale organica a 80

Il limite di 63.206 caratteri per i post di Facebook è perlopiù curiosità; in pratica i post sotto gli 80 caratteri ottengono circa il 30% di engagement organico in più rispetto a quelli più lunghi (HubSpot lo riporta in modo costante negli anni). Sopra la piega, desktop mostra circa 477 caratteri; mobile taglia intorno a 125.

Il massimo per commento è 8.000 caratteri. Reazioni, condivisioni e click-through pendono tutti verso post più brevi: il copy lungo appartiene all’articolo linkato, non alla didascalia Facebook.

Piattaforme più recenti — Bluesky, Mastodon, Threads, TikTok

Bluesky i post si fermano a 300 caratteri e sono il caso insolito: Bluesky conta i grapheme cluster, quindi l’emoji famiglia da sette codepoint 👨‍👩‍👧‍👦 costa 1 carattere, non 7
Mastodon ha default a 500 caratteri per toot, ma gli admin dell’istanza possono alzarlo a 5.000 o anche illimitato; controlla l’istanza da cui pubblichi
Threads usa limiti stile Twitter da 500 caratteri con conteggio per codepoint
TikTok le didascalie permettono 2.200 caratteri con circa 100 mostrati sopra la piega

Reddit, Discord, Slack — long-form e default di community

Reddit titolo 300 caratteri (i moderatori dei subreddit spesso impongono <60 via AutoModerator); commenti 10.000 caratteri
Discord messaggio standard 2.000 caratteri; descrizioni embed 4.096; Nitro alza a 4.000 sui messaggi semplici
Slack messaggio 40.000 caratteri; sopra i 2.000 la leggibilità crolla nettamente e molti destinatari ignorano i messaggi lunghi

Target di word count per tipo di contenuto

I limiti di caratteri dominano social e SEO; il word count domina tutto il resto: lavoro accademico, fatturazione, content marketing, manoscritti. La tabella sotto offre un intervallo target e una stima del tempo di lettura (230 wpm, la mediana della meta-analisi di Brysbaert 2019 sulla lettura silenziosa) per ogni tipo di contenuto comune.

Tipo di contenuto	Target di parole	Tempo di lettura @ 230 wpm	Note
Tweet	30-40 parole	10 sec	ottimizza per carattere, non per parola
Post LinkedIn (zona ottimale)	170-250 parole	1 min	sopra la piega
Didascalia Instagram (hook)	20-25 parole	<10 sec	primi 125 caratteri
Articolo blog — breve	500-700 parole	2-3 min	listicle, news, hot take
Articolo blog — standard	1.000-1.500 parole	4-7 min	tutorial, guida approfondita
Articolo blog — lungo	2.000-3.000 parole	9-13 min	guida completa
Pagina pillar SEO	2.500-5.000 parole	11-22 min	autorevolezza topica
Saggio accademico (liceo)	500-1.500 parole	2-7 min	varia per compito
Saggio accademico (triennale)	1.500-3.000 parole	7-13 min	per compito
NaNoWriMo giornaliero	1.667 parole/giorno	—	50K parole in 30 giorni
Romanzo — breve	50.000-70.000 parole	—	YA, giallo
Romanzo — standard	80.000-100.000 parole	—	narrativa adulta
Talk a conferenza (12 min @ 130 wpm)	1.500-1.600 parole	parlato	prova in lettura per confermare
Episodio podcast (30 min @ 130 wpm)	3.900 parole	parlato	parte scriptata

Il tempo di lettura è l’unità target più utile per il content marketing: i lettori rispondono a un’etichetta “lettura di 5 minuti” in modo più affidabile che a una “1.150 parole”. Il word count resta l’unità per la fatturazione (traduzioni fatturate per parola sorgente), la compliance di piattaforma (i 50K di NaNoWriMo, il tetto accademico di 2.000 parole) e i termini contrattuali. Il Contatore di parole mostra entrambi in tempo reale mentre scrivi, più il tempo di parlato a 130 wpm per talk e podcast.

6 errori di conteggio che rompono app reali

Questi sono i fallimenti ricorrenti visti in codice spedito in produzione e in campagne di marketing già lanciate. Ognuno è abbinato al sintomo, alla causa principale e alla correzione.

Errore 1: usare `string.length` per la validazione del limite di caratteri

Sintomo: un utente incolla un tweet con tre emoji che in realtà è di 270 codepoint. La tua validazione front-end dice 276 e rifiuta l’invio. Oppure, peggio, il tuo codice accetta una bozza da 285 codepoint perché il budget emoji si annulla, e Twitter la rifiuta lato server.

Causa principale: String.prototype.length in JavaScript restituisce code unit UTF-16. Ogni emoji è una coppia surrogata, costa 2 unità. Ogni carattere del piano astrale (simboli matematici, scritture antiche) fa lo stesso.

Correzione: itera per codepoint con l’operatore spread o Array.from.

// ❌ wrong
function isUnderTwitterLimit(text) {
  return text.length <= 280;
}

// ✅ correct
function isUnderTwitterLimit(text) {
  return [...text].length <= 280;
}

Per pattern più approfonditi di iterazione per codepoint basata su regex (incluso il trattamento dei grapheme cluster), il Cheat Sheet delle Espressioni Regolari copre i flag /u e /v e gli escape di proprietà Unicode.

Errore 2: dividere il testo CJK sugli spazi bianchi per il word count

Sintomo: un articolo cinese da 500 caratteri viene riportato come 1 parola. Il preventivo di traduzione basato su quello sbaglia di 500 volte.

Causa principale: le lingue CJK non usano spazi tra le parole. text.split(/\s+/) restituisce un singolo token che contiene l’intero saggio.

Correzione: conta ogni ideogramma CJK come una parola, la convenzione usata da Microsoft Word, Google Docs e ogni word processor CJK nativo.

function countWordsMixed(text) {
  const cjk = (text.match(/[一-鿿぀-ヿ가-힯]/g) || []).length;
  const latin = (text
    .replace(/[一-鿿぀-ヿ가-힯]/g, ' ')
    .match(/[A-Za-z0-9]+(?:['’-][A-Za-z0-9]+)*/g) || []).length;
  return cjk + latin;
}

Gli intervalli Unicode coprono CJK Unified Ideographs (U+4E00 a U+9FFF), Hiragana e Katakana (U+3040 a U+30FF), e Hangul Syllables (U+AC00 a U+D7AF): i quattro blocchi che il word count di Microsoft Word conta come ideogrammi.

Errore 3: dimenticare la sostituzione URL da 23 caratteri di Twitter

Sintomo: una bozza mostra 320 caratteri nel tuo contatore, incluso un URL da 80 caratteri. Spendi 10 minuti a tagliare, solo per scoprire che Twitter avrebbe accettato l’originale a 263 caratteri.

Causa principale: Twitter sostituisce ogni URL con un link t.co da 23 caratteri al momento della pubblicazione. Il tuo contatore grezzo non lo sa.

Correzione: pre-calcola la lunghezza pubblicata usando raw − URL_length + 23 per ogni URL. Per bozze con più URL, somma le correzioni. Il rilevamento URL nei contenuti pubblicati segue RFC 3986, le stesse regole di parsing che la guida Codifica e decodifica URL attraversa passo passo.

Errore 4: scrivere meta description a 320 caratteri (vecchia linea guida)

Sintomo: hai costruito una meta description da 280 caratteri con la CTA in coda. Nei risultati di ricerca Google, la descrizione viene tagliata a metà frase al carattere 158 e la CTA non appare mai.

Causa principale: tra dicembre 2017 e maggio 2018, Google ha brevemente espanso la visualizzazione della meta description a 320 caratteri. Molti tutorial SEO citano ancora quel numero. Google è tornata a ~160 a metà 2018 e da allora è rimasta lì.

Correzione: scrivi entro 150-160 caratteri. Metti la keyword primaria nei primi 30 caratteri e la CTA negli ultimi 30. Usa un simulatore SERP pixel-accurato per pagine ad alto valore: i glifi larghi (W, M, K) mangiano il budget più in fretta di quelli stretti (i, l, t).

Errore 5: confondere 280 caratteri con 280 parole

Sintomo: qualcuno in team scrive “ci serve un tweet da 280 parole” e produce 1.500 caratteri di prosa perfettamente decente. Il tweet non si pubblica.

Causa principale: confusione tra carattere e parola. Le due unità differiscono di circa 5-6 volte per prosa inglese.

Correzione: fissa la regola per piattaforma. Twitter, SMS e meta SEO contano caratteri. NaNoWriMo, compiti accademici, contratti di traduzione e la maggior parte dei brief di content marketing contano parole. In caso di dubbio, controlla il contatore della piattaforma stessa (la compose box di Twitter, Review > Conteggio parole di Word) prima di bloccare la specifica.

Errore 6: incollare virgolette tipografiche che fanno passare silenziosamente SMS a UCS-2

Sintomo: copi un template di ricevuta cliente da Google Doc nel tuo sender SMS. L’originale era 145 caratteri e partiva come un segmento GSM-7. Dopo l’incolla, sono gli stessi 145 caratteri ma vengono fatturati come 2 segmenti UCS-2. I costi raddoppiano su una campagna da un milione di messaggi.

Causa principale: Google Docs e Word convertono automaticamente " e ' in virgolette tipografiche " " e ' '. Quelle virgolette non sono nel set di caratteri GSM-7, e questo ribalta l’intero messaggio in UCS-2.

Correzione: normalizza prima della trasmissione:

function toGsm7Quotes(s) {
  return s
    .replace(/[“”]/g, '"')   // " " → "
    .replace(/[‘’]/g, "'")   // ' ' → '
    .replace(/[–—]/g, '-');  // – — → -
}

Esegui questo prima degli invii sensibili alla fatturazione. Twilio, MessageBird e Bandwidth espongono tutti un campo encoding sulla risposta: loggalo e fai partire un alert quando UCS-2 compare in template che intendevi come GSM-7.

FAQ

Qual è la differenza tra conteggio caratteri e word count?

Il conteggio caratteri conta ogni carattere inclusi spazi, punteggiatura ed emoji, misurato per codepoint Unicode sulla maggior parte delle piattaforme moderne. Il word count conta token separati da spazi bianchi per le scritture latine e ideogramma per ideogramma per le lingue CJK. Twitter, SMS e meta description SEO usano il conteggio caratteri. I saggi accademici, i manoscritti di NaNoWriMo e le fatture di traduzione usano il word count.

Perché Twitter conta un emoji come 1 carattere ma JavaScript lo conta come 2?

Twitter misura per punto di codice Unicode: ogni emoji è un codepoint, un carattere. string.length di JavaScript misura code unit UTF-16. La maggior parte degli emoji è sopra U+FFFF e viene codificata come coppia surrogata in UTF-16, quindi occupa due code unit e .length restituisce 2. Usa [...text].length o Array.from(text).length per ottenere il conteggio codepoint che Twitter conta davvero.

Perché il limite caratteri SMS a volte è 160 e altre volte 70?

Gli SMS usano di default la codifica GSM-7 a 7 bit, che dà 160 caratteri in un payload da 140 byte. Se il messaggio contiene un qualunque carattere non-GSM-7 (emoji, virgolette tipografiche, CJK, latini accentati oltre a un piccolo insieme), l’intero messaggio passa alla codifica UCS-2 a 16 bit e il limite per segmento scende a 70 caratteri. Un singolo emoji ovunque nel messaggio innesca il passaggio.

Qual è la lunghezza ideale della meta description nel 2026?

Punta a 150-160 caratteri. La SERP desktop di Google tronca intorno ai 155-165 a seconda della larghezza in pixel; il mobile taglia tra 100 e 120. Sotto i 120 caratteri Google spesso sostituisce la tua descrizione del tutto con un passaggio dal corpo della pagina. Apri con la keyword primaria nei primi 30 caratteri e chiudi con la CTA negli ultimi 30, così il messaggio sopravvive al troncamento da entrambi i lati.

Il limite di caratteri include spazi ed emoji?

Sì, su praticamente ogni piattaforma. Spazi, a-capo, punteggiatura ed emoji contano ciascuno come un codepoint Unicode. Due eccezioni che vale la pena conoscere: gli SMS dove gli emoji innescano il passaggio di codifica descritto sopra, e Bluesky che conta grapheme cluster quindi un emoji multi-codepoint come la famiglia 👨‍👩‍👧‍👦 costa 1 carattere invece di 7.

Come si calcola il word count per testo cinese, giapponese, coreano?

Ogni ideogramma CJK conta come una parola, la convenzione usata dal word count in modalità cinese di Microsoft Word, da Google Docs, dagli editor CJK nativi e da ogni sistema commerciale di translation memory. Un saggio cinese da 500 caratteri viene riportato come 500 parole. Il testo misto conta gli ideogrammi CJK per carattere e i token latini per spazi bianchi, sommando i due.

Come gestisce Twitter la lunghezza degli URL nel limite di 280 caratteri?

Twitter avvolge automaticamente ogni URL in uno short link t.co da 23 caratteri al momento della pubblicazione, indipendentemente dalla lunghezza originale. La lunghezza pubblicata segue la formula published = raw − URL_length + 23 per URL. Una bozza da 320 caratteri che contiene un URL da 100 caratteri risulta di 243 caratteri. Twitter riconosce gli URL tramite i pattern RFC 3986, quindi query string e fragment vengono assorbiti nel token URL.

Letture correlate

Cheat Sheet delle Espressioni Regolari — pattern matching per la validazione di caratteri, escape di proprietà Unicode
Guida al Text Diff online — confronto di due frammenti di testo, riga per riga e carattere per carattere
Guida alla codifica e decodifica URL — regole di escape dei caratteri quando il testo viaggia attraverso URL
Capire Base64 — l’altra metà della codifica “bit dentro caratteri”, applicata a email e dati binari