Your upload handler should not start with a wall of extensions you copied once and never updated.
Someone drops a path on you: config, source, markup, or something that only looks innocent. You could open every file and sniff bytes. You could paste another team's extension array into yours and hope it stays current. Either way you spend time on bookkeeping before the real work starts.
Text Extensions is the small library that answers "does this path look like text?" from a shared catalog so you can branch early.
One maintained list beats another hand-rolled whitelist.
What you get
- A fast yes or no on extensions and paths. Check a bare extension or a full path, with matching that ignores case and handles leading dots the way real filenames do.
- Hundreds of text types in one place. Source, markup, configs, data formats, and docs sit in a single immutable set aligned with the widely used list this project ports.
- Cheap lookups at scale. Membership uses a frozen set so repeated checks stay light in hot paths.
- The raw sets when you need custom rules. Import the full catalog or its lowercase view when you want to layer your own allow or deny logic on top.
- Nothing extra to install. Zero dependencies and a narrow job: classify by extension and path shape, not by reading file bytes.
Picture your pipeline
An illustrative case: your service accepts user uploads before a parser runs. For each filename you ask whether the path looks like text. Dotfiles such as ignore files count. Mixed-case extensions count. When the answer is no, you reject or route to binary handling without opening the file. When the answer is yes, you still run your encoding checks if you need proof the bytes are really text.
