How We Count Characters
To keep pricing fair and transparent, we count characters based on actual usage, including what gets translated and what gets persisted for future reuse.
What Is Counted as a Character?
We follow Unicode character count (UTF-16 code units). This includes:
- Letters, numbers, punctuation, and symbols
- Spaces and line breaks
- Emojis and non-Latin characters (e.g. Chinese, Arabic)
What Character Types Are Counted
We charge based on two main types of characters:
1. New Translation Characters
These are characters that are:
- Not found in your application cache
- Not found in your persist string
🧾 Example: If you translate a 100-character string into 3 languages, it counts as 300 characters.
2. Persisted Source Characters
These are characters that you:
- Mark as persist(by default), which persist in the DB for review and editing
🧾 Example: If a 200-character source string is saved to DB for 2 locales, we count 400 characters total for each billing cycle.
🧾 Note: When a string is first time persisted (translate and store):
- The translation characters are not counted again in the billing cycle
- Only the source string characters are counted if it's a new string
🧾 Example 1: If you translate and persist a 100-character string into 3 languages:
- Translation count: 300 characters (100 × 3)
- Persist count: 300 characters (100 × 3)
- Total counted: 300 characters for each billing cycle, as the translation count not considered
🧾 Example 2: If you translate a 100-character string into 3 languages without persisting:
- First Time Translation count: 300 characters (100 × 3)
- Second Time Translation count: 300 characters (100 × 3)
- Total counted: 600 characters for current billing cycle
What’s Not Counted
- Strings served from local cache
Billing Cycle
- Character count resets every billing cycle
- Persisted keys are counted once for each billing cycle, not on every access
- Translation characters are counted only if not cached
How Many Characters Might Your App Have?
Understanding your app's size helps choose the right plan and estimate translation needs. Here's a practical guide based on real-world examples:
Typical UI Character Examples
| UI Element | Estimated Characters |
|---|---|
| "Welcome to our app" | 20 |
| Button: "Submit" | 6 |
| Input label: "Email address" | 14 |
| Error message: "Invalid password" | 18 |
| Modal title + description | 100–300 |
| FAQ or Help Article | 300–1,000 |
- Average app string (per key): 15–50 characters
- Small project: 200–500 keys (3,000–25,000 total characters)
- Small-medium project: 500–1,500 keys (7,500–75,000 total characters)
🌍 How Many Languages Do People Translate To?
| Translation Target Locales | Common Use Case |
|---|---|
| 2 | Personal project, hobby app, MVP testing |
| 5–10 | Production app, key global markets |
| 10+ | Enterprise SaaS, global customer base |
🧮 Character Usage Examples
| App Size | Languages | Source Characters | Total Characters Used |
|---|---|---|---|
| Small app (200 keys × 20 chars = 4,000) | 2 languages | 4,000 | 4,000 × 2 = 8,000 |
| Small app (250 keys × 20 chars = 5,000) | 2 languages | 5,000 | 5,000 × 2 = 10,000 |
| Small-medium app (500 keys × 30 chars = 15,000) | 10 languages | 15,000 | 15,000 × 10 = 150,000 |
| Medium app (750 keys × 25 chars = 18,750) | 5 languages | 18,750 | 18,750 × 5 = 93,750 |
| Large app (1,000 keys × 40 chars = 40,000) | 8 languages | 40,000 | 40,000 × 8 = 320,000 |
💡 Key Insights
- Small projects (2 languages): Typically use 8,000-10,000 characters. Great for testing, MVPs, and personal projects.
- Production apps (5-10 languages): Usually require 50,000-150,000 characters for comprehensive localization.
- Enterprise apps (10+ languages): Often need 200,000+ characters for global customer bases.
💡 You can view your real-time usage in our dashboard once you integrate.