How IndicConverter is researched and tested
Converters are not published from a guessed character table. Each legacy profile is researched, implemented and tested as its own compatibility target.
1. Identify the exact profile
We first establish what the converter is actually supposed to support: a named encoding, font version or documented profile. Similar family names are not automatically treated as byte-compatible.
2. Check the mapping basis and licence
Implementation data must come from a documented source or a reusable source with suitable licensing. If the exact profile cannot be established cleanly, the candidate is not presented as supported.
3. Reproduce real conversion behavior
Legacy Indic encodings often need more than one-character substitution. Matras, reph, conjuncts, half forms, nukta handling and historical aliases can require ordered transformation steps. The implementation is built around the behavior of the documented profile rather than a generic transliteration shortcut.
4. Cross-check against independent references
Where an independent implementation, published example or compiled converter exists, it is used as a reference for differential checks. For some profiles this allows exhaustive comparison of all one-byte or two-byte legacy inputs.
5. Test both directions
Reverse conversion is not assumed to be automatically correct because forward conversion works. Unicode → legacy output is tested separately, and conservative fallback is used where an exact legacy representation cannot be verified safely.
6. Stress difficult text
Test suites include structured script forms, real words, mixed Indic and English text, punctuation, URLs and email addresses, malformed legacy sequences, deterministic fuzz cases and long text blocks. Edge cases that expose a bug become regression tests.
7. Test the actual website
In addition to conversion-engine tests, the live site is checked in a real browser for desktop and mobile layouts, sample conversion, copy, paste, download, swap behavior, route loading, canonical tags, sitemap coverage and localized pages.
8. Publish measured evidence, not a single marketing percentage
Different profiles have different reference material and different ambiguity limits. For that reason IndicConverter publishes profile-specific counts and limitations on the Accuracy & supported formats page rather than claiming one universal accuracy percentage.
What can still go wrong?
A document may use a customized font that shares a familiar name but changes character positions, or it may contain mixed legacy and ordinary Latin text that cannot be distinguished perfectly without original formatting. That is why the supported profile is named clearly and why important output should still be proofread.
If you find a reproducible mismatch, report it with the smallest safe sample. A confirmed edge case can be turned into a permanent regression test.