Compteur de Caractères

À Propos de l'Outil Compteur de Caractères

Compter des caractères paraît trivial — mais "combien de caractères contient cette chaîne ?" admet quatre réponses légitimes selon la couche interrogée : octets (UTF-8, ce que le stockage cloud facture), unités de code (morceaux UTF-16, ce que renvoie str.length en JavaScript et ce que limite NVARCHAR de SQL Server), points de code (caractères Unicode, ce que produit l'itération de chaîne en Python 3 et en JS moderne), ou grappes de graphèmes (ce que l'œil humain perçoit comme un caractère). Les quatre peuvent diverger nettement — l'emoji famille 👨‍👩‍👧‍👦 est 1 graphème mais 7 points de code, 11 unités UTF-16 et 25 octets UTF-8. Ce compteur reporte les graphèmes, donc le nombre colle à ce que vous voyez à l'écran, et expose séparément les mots, lignes, paragraphes et phrases via détection de frontières Unicode (UAX #29). Comme les limites de chaque plateforme dépendent de la couche — Twitter/X compte le CJC pour 2, le SMS GSM-7 empaquette 160 caractères ASCII en 140 octets et chute à 70 dès qu'un emoji apparaît (UCS-2), les titres SEO Google se mesurent en pixels (~580 px) et non en caractères, et les tokenizers de LLM consomment ~4 caractères par jeton pour l'anglais mais 1-2 pour le français accentué — utilisez ce compteur pour rédiger puis revalidez sur le compteur officiel de la plateforme avant publication. Le comptage tourne localement avec un debounce de 300 ms ; rien n'est envoyé. Voir aussi notre Convertisseur de Casse et le Générateur Lorem Ipsum.

Pourquoi les nombres de caractères diffèrent-ils entre cet outil, Microsoft Word et Twitter ?

Différentes plateformes comptent les caractères selon des règles différentes. Cet outil compte chaque point de code Unicode, traitant chaque glyphe visible comme une unité. La fonction « Caractères » de Microsoft Word rapporte deux nombres — avec et sans espaces — et peut exclure les notes de bas de page par défaut. Twitter/X est le plus complexe : il compte les URL comme 23 caractères indépendamment de la longueur réelle (encapsulation de lien), compte la plupart des emojis comme 2 caractères, traite les plages Han/Hangul/Hiragana comme 2 caractères chacun, et applique une formule pondérée dans son API. Pour rester en sécurité sous les limites de plateforme, comptez toujours avec le compteur officiel de chaque plateforme pour validation finale ; cet outil sert au brouillon général et est conservateur.

Comment les emojis, les lettres accentuées et les caractères combinants sont-ils comptés ?

Le comptage naïf de caractères peut donner des résultats surprenants car le modèle Unicode sous-jacent est plus complexe que « un caractère = un comptage. » Un emoji simple comme 😀 est un point de code et un caractère perçu — direct. Mais un emoji de famille 👨‍👩‍👧‍👦 est techniquement quatre points de code d'emoji joints par trois jointures sans largeur — sept points de code, un glyphe visible. Les lettres accentuées peuvent être un point de code précomposé (é, NFC) ou deux combinés (e + ́, NFD). Cet outil compte les caractères perçus (grappes de graphèmes) quand possible, donc 👨‍👩‍👧‍👦 lit comme 1. La propriété str.length de JavaScript retourne toujours le compte de points de code — différents outils peuvent diverger par conception.

Quel est le compte optimal de caractères pour les balises title SEO et meta descriptions en 2026 ?

La SERP de Google rend les titres en environ 580 pixels et les descriptions en environ 920 pixels de largeur, pas un compte fixe de caractères — les lettres larges (W, M) prennent plus d'espace que les étroites (i, l). Comme proxy pratique, visez : titres 50-60 caractères (mobile tronque plus tôt à 50), descriptions 120-160 caractères (mobile montre ~120, bureau ~160). Le français avec ses accents et apostrophes prend légèrement plus de pixels. Google ne pénalise pas le texte plus long ; il tronque juste avec des points de suspension, ce qui peut nuire au CTR. Placez les mots les plus importants en premier. Pour d'autres plateformes : titres Open Graph 60-90, descriptions ~200 ; cartes Twitter 70/200 ; partages LinkedIn 150 titres, 250 descriptions.

Que dit WCAG 2.2 sur le compte idéal de caractères par ligne pour l'accessibilité ?

Le Critère de Succès 1.4.8 de WCAG 2.2 (Présentation Visuelle, Niveau AAA) recommande une longueur de ligne maximale de 80 caractères (40 pour le chinois, japonais et coréen). La recherche d'études typographiques converge sur 50-75 caractères par ligne comme optimal pour la vitesse de lecture et la compréhension — des lignes plus courtes (sous 40) forcent trop de sauts oculaires ; des lignes plus longues (sur 90) font perdre aux lecteurs leur place en retournant commencer une nouvelle ligne. Pour le texte de corps sur le web, définissez CSS max-width à environ 65ch (l'unité ch équivaut à la largeur du caractère 0). Cet outil compte les caractères totaux dans le texte entier, pas par ligne — pour vérifier les comptes par ligne, divisez par sauts de ligne et mesurez chaque sous-chaîne.

Comment fonctionnent les segments SMS et pourquoi un emoji divise-t-il mon texte en plusieurs messages ?

Le SMS utilise deux encodages. GSM-7 (par défaut) emballe 160 caractères dans un SMS de 140 octets en utilisant des chars 7-bits — fonctionne pour l'ASCII plus des accents basiques (é, à, ç vont bien ; d'autres déclenchent le repli). UCS-2 (Unicode) est utilisé dès qu'un caractère hors de GSM-7 apparaît — y compris emojis, guillemets courbes, tirets cadratin ou de nombreux diacritiques vietnamiens — et réduit la capacité à 70 caractères par segment. Le SMS multi-segments utilise 153 (GSM) ou 67 (UCS-2) par segment car les en-têtes de routage prennent le reste. Donc un message de 100 caractères avec un emoji devient UCS-2 et s'étend sur deux segments (140 chars totaux facturés comme 2 messages). Twilio et autres passerelles facturent par segment, pas par caractère. Retirez les guillemets courbes et emojis pour garder les textes en segments GSM-7 uniques.

Quelle est la différence entre octets, points de code, unités de code et grappes de graphèmes ?

Ces quatre couches sont la source de la plupart des confusions sur le comptage de caractères. Octets : les octets bruts dans le fichier encodé (UTF-8 utilise 1-4 octets par point de code). Unités de code : les morceaux de 16 bits en UTF-16 (chaînes JavaScript et Java, API Windows) — les emojis au-dessus de U+FFFF utilisent 2 unités de code. Points de code : caractères Unicode réels (U+1F600 pour 😀) — l'itérateur de chaîne dans les langages modernes retourne des points de code. Grappes de graphèmes : ce que les humains perçoivent comme un caractère — 👨‍👩‍👧‍👦 est 1 graphème mais 7 points de code, 14 unités de code UTF-16, 25 octets UTF-8. Cet outil rapporte le compte de graphèmes perçu par l'utilisateur.

Comment puis-je estimer le temps de lecture à partir du compte de caractères ou de mots pour les articles de blog ?

La vitesse moyenne de lecture silencieuse des adultes en français est de 195-240 mots par minute (WPM) ; à voix haute c'est plus lent à 140-150 WPM. Le contenu technique ralentit les lecteurs à 50-100 WPM. Pour estimer le temps de lecture : divisez le compte de mots par 210 (par défaut Medium pour le français) et arrondissez au-dessus. Pour d'autres : anglais 238, espagnol 220, portugais 215, vietnamien 180 — les langues asiatiques sans espaces sont souvent mesurées en caractères par minute (chinois ~300 cpm). Les estimations basées sur caractères sont utiles quand les limites de mot ne sont pas claires : divisez les caractères totaux (avec espaces) par 1 300 pour obtenir des minutes pour le français. Ce compteur montre mots et caractères ; multipliez ou divisez pour calculer le temps de lecture.

Comment les comptes de jetons LLM se rapportent-ils aux comptes de caractères pour l'estimation du coût des prompts ?

Les grands modèles de langue (GPT, Claude, Llama, Gemini) facturent par jetons, pas par caractères. Comme règle approximative pour le texte anglais, 1 jeton ≈ 4 caractères ≈ 0,75 mot. Donc un paragraphe de 1 000 caractères fait environ 250 jetons. Mais ce ratio varie dramatiquement : le code utilise moins de caractères par jeton (~3) car la syntaxe est dense ; le non-anglais utilise plus de caractères par jeton car les tokeniseurs BPE ont été entraînés principalement sur l'anglais. Le français moyenne ~3,3 caractères par jeton (mieux que le vietnamien), mais les accents et la cédille consomment encore plus. Pour budgéter précisément les coûts d'API, utilisez le tokeniseur officiel du modèle (tiktoken pour OpenAI, anthropic-tokenizer pour Claude). Ce compteur de caractères donne une première estimation rapide : divisez les caractères par 3,3 pour des prompts chargés en français.

Exemples de Résultats