快速且准确的文本内容文件类型识别

# Fast And Accurate Text Content File Type Identification
Source: [https://arxiv.org/html/2609.21306](https://arxiv.org/html/2609.21306)
Michael BrautbarAffiliation:CrowdStrike, Inc\., USA michael\.brautbar@crowdstrike\.comEdward RaffAffiliation:CrowdStrike, Inc\., USA edward\.raff@crowdstrike\.com Univ\. of Maryland, Baltimore County, USA raff\.edward@umbc\.edu

###### Abstract

A common requirement across organizations is to have a tool that can identify file types based on their contents, particularly in the cybersecurity domain where magic numbers and file extensions can not be trusted\. While existing tools work well in practice, there is plenty of room for improvement either in terms of computational load and time for detection in the case of model based tools like Magika\[[1](https://arxiv.org/html/2609.21306#bib.bib1)\]or in terms of accuracy of detection in the case of file parsing tools that use programming language constructs\. In this study, we propose a neural network model for identification of types of text content files, especially source code, that is more accurate and faster than other available tools\. Our experiments on open\-source files indicate that it is not only more accurate on average for text\-content file\-type identification, but also approximately four times faster than Magika, while being 28% smaller in size\.

## IIntroduction

A wide variety of tools has been developed over the years to identify file types based on their contents, a ubiquitous need in common computer applications\. Multiple domains, ranging from web applications to cybersecurity, have a critical need for such a tool\. In the cybersecurity domain, file type detection has several applications such as malware detection, policy enforcement, and data protection\. Depending on the identified file type, there might be multiple actions taken such as \(1\) invoking another model based or heuristic mechanism to determine if it is malicious and blocking the file execution or logging it, or \(2\) prevent ex\-filtration attempts by blocking attempts to upload files to the internet if they are in one of the programming languages that an organization uses for development\. Such actions are crucial to maintain a good security posture, and the use of these tools is one of the preliminary steps that are commonly taken in cybersecurity solutions\. The same concerns also apply to the usage of such tools in web applications, where only some file types are allowed to be uploaded to prevent the spread of malware\. Other applications include software development tools \(for e\.g\., Visual Studio Code\) for syntax highlights and web browsers to decide how to render file content in different formats\.

Considering the security\-focused applications of these tools, it is important to prevent simple methods of evasion of detection, such as by renaming file extensions, by designing them to identify the file types from the file contents\. Given the volume of files and their ever\-increasing size, the tools need to be very quick to detect file type while having high detection accuracy\. If the detection time is more than a few milliseconds, the end user will have a bad experience and risks administrators and users disabling this important functionality\. In addition, if such methods are computationally complex, they will again adversely affect end users’ experience by imposing high computational load when running the detection tools, thereby consuming all CPU resources\.

The existing solutions are typically either model\-based or signature\-based\. An example of a model\-based solution is Magika\[[1](https://arxiv.org/html/2609.21306#bib.bib1)\], an open\-source tool reported to achieve state\-of\-the\-art performance in not only text content file type identification but also binary file type identification\. Signature\-based file\-type identification, though widely used and computationally lightweight, has been found to perform relatively poorly in practice for text\-file\-type identification\. Specifically, the areas of weakness of the current approaches in general are the following:

- •Low accuracy of file type identification for text content file types, especially for signature\-based methods\. Applications such as cybersecurity require very high accuracy, without which downstream systems can fail\.
- •High computational requirements for model\-based methods\. It is not uncommon for a large number of files to require simultaneous file\-type identification, for example, when files are uploaded to a website\. Fast file type identification methods with low memory and CPU footprints are a necessity in these situations to ensure good user experience\.
- •Evaluation on proprietary data\. Evaluation of methods on publicly available data would facilitate comparison and benchmarking\.

Magika, in particular, was found to yield high accuracy across most of our use cases\. However, it was slower than needed, with it taking close to 4 milliseconds to identify a single file’s type even while using multiple CPUs\. In addition, multiple file types that needed to be identified were not supported, e\.g\., AppleScript and ColdFusion\. In this study, we proposeLabeler, a neural network model designed specifically for files with text content, such as source code, configuration file formats and markup languages, that is more accurate and faster than Magika\. To efficiently process text content files, we also propose a custom lightweight tokenizer that converts file contents into integer tokens for consumption by the model\. As validated in our experiments,Labelerachieves a MacroF​1F1that is 8% higher than Magika, with individual file\-types often 10 to 20 percentage points better, while being 28% smaller and running close to 4 times faster, a Pareto improvement\.

## IIRelated Work

The other methods for file type identification can be broadly classified into two groups: \(1\) Signature\-based and \(2\) Model\-based, as described below\.

### II\-ASignature\-Based File Type Identification

For text content file types, signature\-based identification uses regular expressions to detect common usage patterns\. The utilityfile\[[2](https://arxiv.org/html/2609.21306#bib.bib2),[3](https://arxiv.org/html/2609.21306#bib.bib3)\]is used in all BSD and Linux distributions\. Similarly, Apache Tika\[[4](https://arxiv.org/html/2609.21306#bib.bib4)\]uses parsers to identify a limited set of text content file types\. These tools and others exiftool\[[5](https://arxiv.org/html/2609.21306#bib.bib5)\]and trid\[[6](https://arxiv.org/html/2609.21306#bib.bib6)\]identify a wide variety of binary file types using “Magic Bytes”, Multipurpose Internet Mail Extensions \(MIME\) types or other file metadata\. Magic bytes are predefined byte sequences that exist at a specific location of the file and are generally found to be good indicators\. Utilities such as file\[[2](https://arxiv.org/html/2609.21306#bib.bib2)\]are reported to be fast and accurate in binary file type identification\[[1](https://arxiv.org/html/2609.21306#bib.bib1)\]\. However, they are easy to adversarially subvert by modifying the magic bytes, making them inappropriate to use in a security context\.

Such methods, though computationally efficient, suffer from low detection accuracy and lack of adaptability for text content file types\. The regular expressions used for file type identification need periodic updates as usage patterns evolve and new features are added to languages\. Hence, there is a need for highly manual work from subject matter experts\. Model\-Based methods can automatically learn the usage patterns most relevant to distinguish between file types if trained with large and updated training sets, so that not only are they more accurate, but also require less manual effort\. With this motivation,Labelerwas designed to be a model\-based method\.

### II\-BModel\-Based File Type Identification

Several approaches have been studied over the years for identifying file types from their contents\. Guesslang\[[7](https://arxiv.org/html/2609.21306#bib.bib7)\]is a neural network model based on a wide and deep network architecture\[[8](https://arxiv.org/html/2609.21306#bib.bib8)\]\. It was trained on 1\.9 million open\-source code files and processes file content by computing bi\-grams from the entire file\. It is used in popular applications, including Visual Studio Code\[[9](https://arxiv.org/html/2609.21306#bib.bib9)\]\. It supports the identification of fifty\-four commonly used source code file types\. The original guesslang implementation is in a deprecated TensorFlow version, but Visual Studio Code developers maintain a version that has a javascript interface\[[10](https://arxiv.org/html/2609.21306#bib.bib10)\]\.

Magika\[[1](https://arxiv.org/html/2609.21306#bib.bib1)\], is reported to have state of the art performance in the identification of more than two hundred file types covering both binary and text types\. It is a deep neural network model that works directly on byte sequences sliced from the file contents\. Specifically, it works on three chunks of byte sequences extracted from the start, middle, and end of the file\. The classifier model works on the three sequences of byte \(i\.e\., three regions extracted from the file content\) to identify the file type\. The model is relatively small, with parameters reported to be approximately 1 MB\. Magika has been integrated into popular applications such as Google Drive and Gmail\. It is also integrated into Apache Tika\[[11](https://arxiv.org/html/2609.21306#bib.bib11)\]\. The model architecture is shown in Figure[1](https://arxiv.org/html/2609.21306#S2.F1)\.

![Refer to caption](https://arxiv.org/html/2609.21306v1/plots/magika.png)Fig\. 1:Magika model architecture from\[[1](https://arxiv.org/html/2609.21306#bib.bib1)\]\. It works on three byte sequences extracted from the start, middle, and end of the files\. The numbers next to the layers’ names indicate the size of their outputs\.Some approaches\[[12](https://arxiv.org/html/2609.21306#bib.bib12),[13](https://arxiv.org/html/2609.21306#bib.bib13)\]use NLP\-based feature extraction with Support Vector Machines or deep learning models\[[14](https://arxiv.org/html/2609.21306#bib.bib14),[15](https://arxiv.org/html/2609.21306#bib.bib15)\]to address the file\-fragment classification problem \(i\.e\., you have an incomplete file, often recovered from a corrupted storage or data stream\) in digital forensics and file recovery\[[16](https://arxiv.org/html/2609.21306#bib.bib16),[17](https://arxiv.org/html/2609.21306#bib.bib17),[18](https://arxiv.org/html/2609.21306#bib.bib18),[19](https://arxiv.org/html/2609.21306#bib.bib19),[20](https://arxiv.org/html/2609.21306#bib.bib20),[21](https://arxiv.org/html/2609.21306#bib.bib21)\]\. These methods are reported to have lower detection performance\[[1](https://arxiv.org/html/2609.21306#bib.bib1)\]than Magika and hence are not widely used outside of forensic contexts where they are truly necessary\. Beyond having to deal with partial file fragments, digital forensics often relies on more complex and heavy\-lift processing techniques to try to mitigate the impact on accuracy\. This includes creating digests based on compression methods, entropy, and other statistics\[[22](https://arxiv.org/html/2609.21306#bib.bib22),[23](https://arxiv.org/html/2609.21306#bib.bib23),[19](https://arxiv.org/html/2609.21306#bib.bib19),[24](https://arxiv.org/html/2609.21306#bib.bib24)\], complex domain knowledge parsing in the face of incomplete data\[[25](https://arxiv.org/html/2609.21306#bib.bib25),[26](https://arxiv.org/html/2609.21306#bib.bib26),[27](https://arxiv.org/html/2609.21306#bib.bib27)\], and neural networks\[[28](https://arxiv.org/html/2609.21306#bib.bib28),[29](https://arxiv.org/html/2609.21306#bib.bib29),[30](https://arxiv.org/html/2609.21306#bib.bib30)\], among many machine learning approaches\[[31](https://arxiv.org/html/2609.21306#bib.bib31),[20](https://arxiv.org/html/2609.21306#bib.bib20)\]\.\[[32](https://arxiv.org/html/2609.21306#bib.bib32)\]proposed using a fine\-tuned BERT model for file\-type identification\. While such approaches could possibly yield good accuracy in file type detection, they suffer from high computational load for inference and are not suitable for the applications described in Section[I](https://arxiv.org/html/2609.21306#S1)\.

A thorough evaluation of guesslang is presented in\[[1](https://arxiv.org/html/2609.21306#bib.bib1)\]along with comparisons against signature\-based tools such asfile, exiftool and trid\. For identification text content file types, guesslang was reported to have an average F1 score of 0\.77, which is higher than file, exiftool or trid\. However, it was significantly lower than the average F1 score of 0\.99 of Magika for the same file types\. In this study, we used only Magika as a baseline, given its reported state\-of\-the\-art performance by a very large margin compared to the other tools, and its widespread usage\. As described in the following sections,Labeleris designed specifically for text content file types with the use of a custom tokenizer, unlike Magika\. It has a custom neural network architecture designed for efficiency and is3\.7×3\.7\\timesfaster despite processing5\.3×5\.3\\timesmore input and using one CPU core instead of multiple\.

## IIIMethod

Given the need for a lightweight, high\-accuracy model to specifically identify text content types, the proposed model uses a simple tokenizer described in the next section\. Similar to the method in\[[1](https://arxiv.org/html/2609.21306#bib.bib1)\], file contents are read in chunks\. However, our solution reads only two chunks of a given file, rather than three like in Magika\. The first 4 Kb and the last 4 Kb of the file are processed as described in Section[III\-A](https://arxiv.org/html/2609.21306#S3.SS1)\. The tokenizer converts the text content in each file chunk \(from start to end\) into a sequence of integers, called tokens, based on a mapping of text substrings to specific integer values\. The two token sequences computed by the tokenizer are processed by the neural network architecture described in Section[III\-B](https://arxiv.org/html/2609.21306#S3.SS2), to train the model\. This enables the model to predict the file type in a fixed time irrespective of file size\. 4 Kb is selected from the start/end of the file because the start/end often have file\-specific meta data or mandatory structures that aid in detection, while also being large enough to extend past such mandatory structures and obtain a large sample of non\-structural content\.

### III\-ATokenizer

Each text content file undergoes tokenization, a process in which text is converted into integer sequences for computational processing\. Our custom tokenization methodology is formalized in Algorithm[1](https://arxiv.org/html/2609.21306#alg1)described below\. We designed the tokenizer with the goal of capturing important symbols in the files without being computationally complex\.

Algorithm 1Text Content Symbol Tokenization0:Text content file

FF
0:Token sequence

TT
1:Split

FFinto lines

L=\{l1,l2,…,ln\}L=\\\{l\_\{1\},l\_\{2\},\\ldots,l\_\{n\}\\\}
2:foreach line

li∈Ll\_\{i\}\\in Ldo

3:Remove leading and trailing whitespace from

lil\_\{i\}
4:Split

lil\_\{i\}into sub\-words

SSseparated by non\-alphanumeric characters

5:foreach sub\-word

sj∈Ss\_\{j\}\\in Sdo

6:if

sjs\_\{j\}is alphanumericthen

7:Split

sjs\_\{j\}at case transitions \(lowercase to uppercase\)

8:Convert all alphanumeric components to lowercase

9:endif

10:Append processed tokens to

TT
11:endfor

12:endfor

13:return

TT

For example, the code fragmentif len\(sub\_part\) == camelPartundergoes the following transformation: initial splitting yieldsif,len,\(,sub,part,\),==,camelPart; subsequent case\-based segmentation ofcamelPartproducescamel,part; and final normalization results in the token sequence:if,len,\(,sub,part,\),==,camel,part\.

This tokenization approach is designed to preserve relevant symbols in source code and configuration files, distinguishing it from conventional natural language processing tokenizers, which typically discard punctuation or employ word\-piece segmentation\. Such traditional methods prove inadequate for our analysis\. For instance, while the model must differentiate betweendefineanddefas distinct tokens, a word\-piece tokenizer\[[33](https://arxiv.org/html/2609.21306#bib.bib33)\]may fragmentdefineintodef,in, ande, thereby obscuring their semantic distinction\.

Although the tokenizer accepts inputs of up to 4 KB, the resulting token sequences may vary in length\. This is due to the fact that sub\-words computed from the input text will have varying lengths, and depending on the nature of sub\-words in the input, the number of tokens in the output varies\. This is handled by truncating the output of the tokenizer to 512 tokens\. In the event that the number of computed tokens is less than 512, the token sequence will be zero\-padded as is general practice in neural networks\.

#### III\-A1Vocabulary Construction

The processed token strings are converted into integer representations through the following procedure:

1. 1\.Compute the frequency of each symbol or sub\-word across the training corpus\.
2. 2\.Rank sub\-words by occurrence frequency in descending order\.
3. 3\.Select theKKmost frequent symbols to form the vocabulary\.
4. 4\.Map each symbol to its corresponding rank\.

Symbols not present in the vocabulary are represented as unknown tokens\. Empirical evaluation revealed that a relatively compact vocabulary size ofK=4096K=4096is sufficient to capture the lexical diversity of programming languages without compromising model performance\.

### III\-BModel Architecture

TheLabelermodel is a dual\-input convolutional neural network designed for programming language classification\. The architecture processes both the beginning and end chunks of text content file types to capture syntactic patterns and structural information characteristic of different programming languages\. The model architecture is shown in Figure[2](https://arxiv.org/html/2609.21306#S3.F2)\. As shown in the figure, several layers operate on each token sequence \(start or end\) independently\. These layers have use weight sharing which enables efficient training of the model and a low memory footprint during inference\.

![Refer to caption](https://arxiv.org/html/2609.21306v1/plots/callisto_v2_arch.png)Fig\. 2:The dual\-input convolutional neural network architecture of theLabelermodel\. The first three rows of blocks show how file contents are processed and the remaining blocks show the layers in the neural network model\. The initial layers: embedding, spatial dropout, and 1\-D Convolution, followed by layer normalization and dropout process, share the parameters, though they process the two token sequences separately\.The shared embedding layer maps discrete tokens to dense vector representations\. A relatively low dimension ofd=16d=16was found to be sufficient to yield good results in this application, and desirable as we wish to minimize compute time and run on CPUs\. The shared 1D\-convolutional layer extracts local features from both sequences, using 64 filters with a kernel size of 4 and a stride of 2\. This layer reduces the sequence length by half for each token sequence\. The concatenation layer concatenates the two sequences along the feature dimension\. The layers following concatenation are similar to the last few layers in Magika and represent the extraction of more detailed features before the final dense layer with softmax activation\. All layers except the final dense layer use the rectified linear unit \(ReLU\)\[[34](https://arxiv.org/html/2609.21306#bib.bib34)\]activation function rather than its more complex variants\[[35](https://arxiv.org/html/2609.21306#bib.bib35)\]to improve efficiency\. The output of the last layer is the vector of probabilities that a given file belongs to each of the output file types\. This architecture yields a model with approximately 715 KB of parameters that supports efficient training and inference\. Our proposedLabelermodel is different from Magika in the following respects:

- •Labelerworks on integer tokens computed by our custom tokenizer\. The file contents are read as text \(after decoding their UTF encoding\), followed by conversion into fragments of text, each of which is then replaced by an integer ID\. Magika does not use a tokenizer and operates directly on raw bytes\.
- •Labelerreads two chunks of files, while Magika reads three \(start, middle and end\)\. In all,Labelerprocesses up to 8KB of file contents while Magika is limited to 1\.5 KB in the version described in\[[1](https://arxiv.org/html/2609.21306#bib.bib1)\]\.
- •Labeleruses a different neural network to deal with the tokenized input, with the use of an embedding layer, which is different from Magika\. In addition, several of the first few layers operate on each token sequence independently, and their outputs are finally concatenated to produce a single feature sequence for the file\.
- •Finally,Labeleris designed for text content file type detection, while Magika is designed for the detection of text content and binary file types\.

## IVEvaluation

TheLabelermodel was evaluated against Magika as the baseline\. As described in Section[II\-B](https://arxiv.org/html/2609.21306#S2.SS2), though there are other methods such as guesslang that also identify text content file types, Magika is reported to be the Pareto optimal solution today: significantly more accurate and has a much faster inference time, due to which we limited our experiments to comparison with Magika\. All experiments used the Python library of Magika \(version 1\.0\.1\) installed from PyPI\. Our custom tokenizer logic described in[1](https://arxiv.org/html/2609.21306#alg1)was implemented in Rust for efficiency\. We note that because Magika calls out to underlying C libraries for byte reading and tensor calculations, and does not have any transformations to implement in Python, this is a fair comparison where each method will be leveraging Python libraries with compiled code for content extraction\.

For all file types, a probability threshold of 0\.5 was used on the output of theLabelerto classify a given file as of a type\. For files for which none of the file\-type probabilities exceed this threshold, the predicted type is set to ‘unknown’\. Magika also returns the label ‘unknown’ when the predicted probability is below a threshold, though the threshold can vary by file type, as defined in the configuration\.

### IV\-ADatasets

#### IV\-A1Dataset Sources

The training dataset is constructed from the BigCode\[[36](https://arxiv.org/html/2609.21306#bib.bib36)\]project, which provides a comprehensive collection of permissively licensed open\-source file repositories\. The primary source is The Stack dataset\[[37](https://arxiv.org/html/2609.21306#bib.bib37)\]\(‘The Stack dedup’\), containing approximately 2\.9 TB of deduplicated files across 358 file types with convenient streaming API access\. For programming languages with insufficient representation in The Stack dataset\- Verilog, MATLAB, ColdFusion, AppleScript, DM, and COBOL, the more comprehensive Stack V2 dataset\[[38](https://arxiv.org/html/2609.21306#bib.bib38)\]was utilized \(‘The Stack v2 dedup’\), encompassing 32 TB of deduplicated files across 658 file types\. Only open\-source files under permissive licenses \(MIT, Apache 2\.0, BSD\-3\-Clause, and BSD\-2\-Clause\) were included, yielding approximately 9\.75 million files, with an 80/10/10 split for training, validation, and testing, respectively\.

#### IV\-A2Language Coverage and Organization

The final dataset encompassesfifty fourdistinct programming languages spanning mainstream languages such as Python, JavaScript, and Java to specialized domain\-specific languages including COBOL, VHDL, and Verilog\. Language families are grouped in this model to improve classification accuracy: C and C\+\+ are unified under a “c\-family” label, Java and Groovy share a “java\-family” classification, and JavaScript variants, including TypeScript, are grouped as “js\-family”\. This hierarchical organization reduces the effective number of output classes while maintaining meaningful distinctions between programming paradigms\. Since Magika does not use such language\-family groupings, Magika’s outputs are mapped to the corresponding labels used by theLabelermodel, enabling comparison between the models\. For example, if Magika predicts a file type of “groovy”, it is first mapped to “java\-family” before the evaluation of the metrics described in this study\. The file types supported by theLabelermodel are shown in Table[II](https://arxiv.org/html/2609.21306#S4.T2)\. File types ActionScript, AppleScript, ColdFusion, coldfusion and Java Server Pages are not supported by the latest version of Magika \(version 1\.0\.1\) at the time of this writing\.

### IV\-BModel Training

The model was trained using the AdamW optimizer\[[39](https://arxiv.org/html/2609.21306#bib.bib39)\]with learning rateα=0\.001\\alpha=0\.001,β1=0\.9\\beta\_\{1\}=0\.9,β2=0\.999\\beta\_\{2\}=0\.999, and gradient clipping withclipnorm=1\.0\\text\{clipnorm\}=1\.0\. The loss function is sparse categorical cross\-entropy, the standard loss for multi\-class classification problems\. Distributed training across the four GPUs on an EC2 instance \(g4dn\.12xlarge\) with a batch size of 2048 and 40 training epochs takes less than eight hours to complete\. AllLabelermodel\-related implementation used the TensorFlow library, and the custom tokenizer for file content processing was done using a Rust implementation\. The dropout rate for the first dropout layer \(spatial dropout\)\[[40](https://arxiv.org/html/2609.21306#bib.bib40)\]was set as 0\.1, while for the second it was 0\.15, and for the third it was 0\.2\. All other layer parameters were set to their default values in the TensorFlow implementation\.

### IV\-CInference Time Measurement

Efficiency evaluation of both models was conducted using controlled timing experiments on a single CPU core with TensorFlow configured to use single\-threaded execution and GPU acceleration disabled\. This setup was intended to replicate its original use case: a file\-identification tool that runs on client machines in the background with minimal impact on other processes\. As mentioned earlier, a model that requires multiple CPUs for inference can lead to undesirable user experience and our measurement method considers such applications also\.

To measure theLabeler’s inference speed, a hundred thousand random byte sequences of 8,192 bytes each were generated\. Time taken to tokenize each byte sequence using a rust implementation of the tokenizer and the neural network model to generate predictions on the tokens is measured\. Similarly, for Magika, a hundred thousand random byte sequences of 1,536 bytes are generated\. Inference time is measured through Magika’sidentify\_bytesmethod\. Both functions exclude the first 100 iterations to account for model initialization overhead and report average inference times in milliseconds per file\. Note that benchmarking was performed on an Apple MacBook Pro \(M1 Max\) withLabelerlimited to one CPU core\. This test was designed to minimize any latency concerns in passing the file contents as arguments to the Magika library\. The controlled experimental setup ensures fair comparison between the two approaches, with the results displayed in Figure[3](https://arxiv.org/html/2609.21306#S4.F3)\.Labelerachieves approximately 1\.05 ms per file compared to Magika’s 3\.85 ms per file, demonstrating nearly 3\.7×\\timesfaster inference speed while also processing5\.3×5\.3\\timesmore bytes, for a net19\.6×19\.6\\timesadvantage per\-byte\.

0011223344550010 00010\\,00020 00020\\,00030 00030\\,00040 00040\\,00050 00050\\,00060 00060\\,00070 00070\\,000Inference time \(ms\)Number of inference callsInference TimeLabeler \(single CPU\)Magika \(no CPU limits\)Fig\. 3:Inference time benchmarked by settingLabelerto use one CPU core only, without any such limitation on Magika\. To measureLabelerinference times, a random byte array is generated of 8 Kb size and fed to a Rust implementation of the custom tokenizer the output of which is fed to the neural network model\. Similarly, to measure Magika’s inference times, a random byte array of size 1\.5 Kb is generated and passed as input to the Python interface of Magika\. The average time taken for hundred thousand such calls is shown here
### IV\-DAccuracy Results

We evaluate model performance using standard classification metrics\. Precision measures the proportion of correct positive predictions for a file type, and Recall measures the proportion of actual positives correctly identified\. F1\-score is the harmonic mean of Precision and Recall\. We report both Macro F1 \(unweighted average of per\-class F1\-scores\) and Weighted F1 \(average of per\-class F1\-scores weighted by class proportion\) across all classes\. Any file classified as ‘unknown’ due to its predicted probability not meeting the threshold of 0\.5 is counted as a false negative for that file’s type\.

TABLE I:Summary of performance metrics comparingLabelerand Magika\.Labelerdemonstrates superior accuracy with both macro and weighted F1\-scores\. Most significantly,Labelerhas 3\.7x faster inference speed even when it is limited to use a single CPU core, unlike Magika\.A summary of the results of the comparison ofLabelerwith Magika is shown in Table[I](https://arxiv.org/html/2609.21306#S4.T1), showing a superior performance in terms of Macro\-F1 and Weighted\-F1\. TheM​a​c​r​o​F1MacroF\_\{1\}score ofLabeleris 0\.98, which is significantly higher compared to Magika’s 0\.91\. Similarly, theW​e​i​g​h​t​e​d​F1WeightedF\_\{1\}score ofLabeleris 0\.982, which is significantly higher than Magika’s 0\.92\. The most significant result is likely the reduction in inference time per file, withLabelerbeing about 3\.7 times faster than Magika\. The faster inference is likely the result of using a smaller model \(Labeleris28%28\\%smaller than Magika\) and the neural network architecture that processes each file chunk independently in the first few layers\. An estimate of the size of the custom tokenizer implementation in Rust can be obtained from the compiled Python wheel \(220 KB\), which includes the vocabulary definition\. Hence, the model and tokenizer together have a lower memory footprint than Magika\.

Table[II](https://arxiv.org/html/2609.21306#S4.T2)shows the per\-class F1\-score for each of the supported fifty\-four file types\. Across all file types,Labelerachieves a higher F1\-score than Magika, with the difference being significantly greater in some cases\.

TABLE II:Performance comparison for some of the supported file types\. Bold values indicate the best results\. – indicate unsupported types\.Labeler’s dominance over Magica is a reflection of careful design in model and feature processing, and reflects a challenge in the canonical deep\-learning paradigm\. While a deep model can often perform better given enough training data and compute \(e\.g\., Convolutional Neural Networks displacing classic Computer Vision designs, Recurrent Neural Networks displacing much of stemming and classical Natural Language Processing, and now Transformers yet\-still displacing RNNs and many NLP sub\-tasks like entity recognition\), this advantage is not necessarily free from a computational efficiency perspective\. Even a simpler tokenizer as we use in Algorithm[1](https://arxiv.org/html/2609.21306#alg1)carefully designed for the domain has yielded significant advantage in accuracy for a tight compute budget\. Such runtime constraints are common in cybersecurity applications\[[41](https://arxiv.org/html/2609.21306#bib.bib41)\]\. As mentioned earlier, if the predicted probability for a file is less than the threshold of 0\.5 for any type, then the file type is taken to be ‘unknown’ and it is counted as an FP\. For all the files in the test set, only0\.8%0\.8\\%of the files have a predicted file type of ‘unknown’\.

0\.30\.30\.40\.40\.50\.50\.60\.60\.70\.70\.80\.80\.90\.911001010202030304040F1\-scoreNumber of file typesModel F1\-Scores on Test SetLabeler F1\-scoreMagika F1\-scoreFig\. 4:Distribution of F1 score for the different file types\. As seen,Labelerhas a much narrower distribution than Magika\. Both model gave least F1\-scores for “text” file type\. However, for other types, the results forLabelershow an F1\-Score of at least 0\.94\.To measure the impact of training set size on the classification performance ofLabeler, we trained the model by setting an upper limit on the number of files in each file type\. The resulting precision and recall are shown in Figure[5](https://arxiv.org/html/2609.21306#S4.F5)\. Note that the same test set files as in the results described above are used here\. It can be seen thatLabeler’s recall is higher than Magika’s, even with only 2000 training files per file type\. The precision is lower than Magika in the case when the training set size is 2000, but higher in all other cases\. These results indicate that theLabelerarchitecture is able to improve upon the state\-of\-the\-art model even with a very low number of training set files\. This again shows the value in having a customized tokenizer and architecture, allowing a large improvement in sample efficiency\. Such advantage is critical from an operational maintenance perspective, as new file types emerge with intrinsically limited availability, we are more likely to be able to produce a satisfying production model in a timely fashion\.

2 0005 00010 00020 00050 000All files0\.90\.90\.920\.920\.940\.940\.960\.960\.980\.98Number of files in training setClassification metricImpact of Training Set SizeLabeler precisionMagika precisionLabeler recallMagika recallFig\. 5:Improvement in precision and recall ofLabelerwith increase in training set size\. Even with a very low number of files per type in the training set,Labelerquickly produces a higher accuracy than Magika using all available training data\. This shows our method has excellent sample efficiency for rare and future new file types\.The key insights from the evaluation are listed below:

- •Labelergives a relatively consistent performance with an F1\-score higher than 0\.94 for all types except text \(\.txt files\)\.
- •BothLabelerand Magika were measured to have the worst performance for text \(\.txt files\)\. This is not very surprising since these are text files from GitHub projects, that are found to have a mix of code/configuration type files in them\. For examples, a few text files have CMake commands in them as part of instructions\.
- •Even for file types that have fewer samples in our training dataset, theLabelerhas a higher F1\-score than Magika\. For the five types supported by both models with the least training set size \- DM, COBOL, R, VHDL, Objective\-C\+\+,Labelerhas aM​a​c​r​o​F1MacroF\_\{1\}of 0\.96 compared to Magik’s 0\.83\. The model architecture seems to be able to learn enough details from even comparatively small training sets for these languages, so it is reasonable to expect the model to learn from other such rare or new languages as and when training data becomes available for them\.

#### IV\-D1Customizability ofLabeler

TheLabelermodel is relatively easy to customize\. Given the availability of ample open\-source code files and the empirically demonstrated ability of the model to identify file types, even when there are comparatively few files of those types in the training set, adding support for new file types is straightforward\. An interesting result on the impact of varying the training set size on the detection of the rare file types \(DM, COBOL, R, VHDL, and Objective\-C\+\+\) is shown in Figure[6](https://arxiv.org/html/2609.21306#S4.F6)\. As expected, the average precision increases with an increase in train set size\. The average recall also increases initially, but then drops slightly, specifically when the maximum training set size per type is 50000 or higher\. This is an expected result due to the fact that all these types have a training set size of less than 50000 in the original training set, leading to an imbalance in the training set when larger sizes\. Note that the same test set as in other experiment results is also used here\. Future research could explore oversampling files from under\-represented types or augmenting data through two approaches: \(1\) combining portions of existing files using language parsers, or \(2\) generating synthetic files using LLMs\.

2 0005 00010 00020 00050 000All files0\.70\.70\.750\.750\.80\.80\.850\.850\.90\.90\.950\.9511Training set size per typeClassification metricImpact of Training Set Size on Rare TypesMagika recallLabeler precisionMagika precisionLabeler recallFig\. 6:Relation of precision and recall for the rarest five file types \(DM, COBOL, R, VHDL, and Objective\-C\+\+\) with increase in training set size\. The drop in recall beyond a size of 50000 is likely due to the fact that all these types have less than 50000 files in the original training set\.

## VConclusion

In this paper, we introduced a lightweight neural network model, Labeler, designed to efficiently and accurately identify text content file types from their contents\. A custom tokenizer algorithm that can be efficiently implemented is also presented, which can process text content files into a format suitable for the model to process\. Similar to the method in Magika, the model reads only chunks of a given file to predict its file type\. Based on extensive experiments on open source files, it was found thatLabelerhas an MacroF​1F1that is8%8\\%higher than Magika while being 3\.7 times faster for inference and about28%28\\%smaller in terms of model parameter size\. These results indicate that the newly proposedLabelermodel has superior performance for the identification of text content file types\.

## References

- \[1\]Y\. Fratantonio, L\. Invernizzi, L\. Farah, K\. Thomas, M\. Zhang, A\. Albertini, F\. Galilee, G\. Metitieri, J\. Cretin, A\. Petit\-Bianco, D\. Tao, and E\. Bursztein, “Magika: AI\-Powered Content\-Type Detection,” in*Proceedings of the International Conference on Software Engineering \(ICSE\)*, April 2025\.
- \[2\]“File — a file type guesser,” 2026\. \[Online\]\. Available:[https://www\.darwinsys\.com/file/](https://www.darwinsys.com/file/)
- \[3\]“libmagic\(3\) \- linux manual page,” 2023, describes the library functions for file type identification\. \[Online\]\. Available:[https://man7\.org/linux/man\-pages/man3/libmagic\.3\.html](https://man7.org/linux/man-pages/man3/libmagic.3.html)
- \[4\]Apache Software Foundation, “Apache Tika toolkit for content analysis,” 2025\. \[Online\]\. Available:[https://tika\.apache\.org/](https://tika.apache.org/)
- \[5\]“Exiftool,” 2026\. \[Online\]\. Available:[https://exiftool\.org/](https://exiftool.org/)
- \[6\]“Trid,” 2025\. \[Online\]\. Available:[https://mark0\.net/soft\-trid\-e\.html](https://mark0.net/soft-trid-e.html)
- \[7\]“guesslang: tool to detect programming language of a given source,” 2021\. \[Online\]\. Available:[https://github\.com/yoeo/guesslang](https://github.com/yoeo/guesslang)
- \[8\]H\.\-T\. Cheng, L\. Koc, J\. Harmsen, T\. Shaked, T\. Chandra, H\. Aradhye, G\. Anderson, G\. Corrado, W\. Chai, M\. Ispir, R\. Anil, Z\. Haque, L\. Hong, V\. Jain, X\. Liu, and H\. Shah, “Wide & deep learning for recommender systems,” in*Proceedings of the 1st Workshop on Deep Learning for Recommender Systems*, ser\. DLRS 2016\. New York, NY, USA: Association for Computing Machinery, 2016, p\. 7–10\. \[Online\]\. Available:[https://doi\.org/10\.1145/2988450\.2988454](https://doi.org/10.1145/2988450.2988454)
- \[9\]“Visual studio code september 2021 \(version 1\.60\) \- automatic language detection,” 2021\. \[Online\]\. Available:[https://code\.visualstudio\.com/updates/v1\_60\#\_automatic\-language\-detection](https://code.visualstudio.com/updates/v1_60#_automatic-language-detection)
- \[10\]“Vscode language detection: nodejs cli around guesslang,” 2026\. \[Online\]\. Available:[https://github\.com/microsoft/vscode\-languagedetection](https://github.com/microsoft/vscode-languagedetection)
- \[11\]“Magikadetector: Apache tika interface documentation,” 2025\. \[Online\]\. Available:[https://tika\.apache\.org/3\.1\.0/api/org/apache/tika/detect/magika/MagikaDetector\.html](https://tika.apache.org/3.1.0/api/org/apache/tika/detect/magika/MagikaDetector.html)
- \[12\]S\. Fitzgerald, G\. Mathews, C\. Morris, and O\. Zhulyn, “Using nlp techniques for file fragment classification,”*Digital Investigation*, vol\. 9, pp\. S44–S49, 2012, the Proceedings of the Twelfth Annual DFRWS Conference\. \[Online\]\. Available:[https://www\.sciencedirect\.com/science/article/pii/S1742287612000333](https://www.sciencedirect.com/science/article/pii/S1742287612000333)
- \[13\]F\. Wang, T\.\-T\. Quach, J\. Wheeler, J\. B\. Aimone, and C\. D\. James, “Sparse coding for n\-gram feature extraction and training for file fragment classification,”*IEEE Transactions on Information Forensics and Security*, vol\. 13, no\. 10, pp\. 2553–2562, 2018\.
- \[14\]G\. Mittal, P\. Korus, and N\. Memon, “Fifty: Large\-scale file fragment type identification using convolutional neural networks,”*IEEE Transactions on Information Forensics and Security*, vol\. 16, pp\. 28–41, 2021\.
- \[15\]K\. Skračić, J\. Petrović, and P\. Pale, “Bytercnn: Enhancing file fragment type identification with recurrent and convolutional neural networks,”*IEEE Access*, vol\. 11, pp\. 138 176–138 187, 2023\.
- \[16\]M\. McDaniel and M\. H\. Heydari, “Content Based File Type Detection Algorithms,” in*Proceedings of the 36th Annual Hawaii International Conference on System Sciences \(HICSS’03\) \- Track 9 \- Volume 9*\. Washington, DC, USA: IEEE Computer Society, 2003, p\. 332\.1, series Title: HICSS ’03\. \[Online\]\. Available:[http://dl\.acm\.org/citation\.cfm?id=820756\.821828](http://dl.acm.org/citation.cfm?id=820756.821828)
- \[17\]A\. Pal and N\. Memon, “The Evolution of File Carving,”*IEEE Signal Processing Magazine*, vol\. 26, no\. 2, pp\. 59–71, Mar\. 2009\. \[Online\]\. Available:[http://ieeexplore\.ieee\.org/document/4806206/](http://ieeexplore.ieee.org/document/4806206/)
- \[18\]V\. Roussev and S\. L\. Garfinkel, “File Fragment Classification\-The Case for Specialized Approaches,” in*Proceedings of the 2009 Fourth International IEEE Workshop on Systematic Approaches to Digital Forensic Engineering*\. Washington, DC, USA: IEEE Computer Society, 2009, pp\. 3–14, series Title: SADFE ’09\. \[Online\]\. Available:[http://dx\.doi\.org/10\.1109/SADFE\.2009\.21](http://dx.doi.org/10.1109/SADFE.2009.21)
- \[19\]S\. Axelsson, “The Normalised Compression Distance as a file fragment classifier,”*Digital Investigation*, vol\. Volume 7,, pp\. S24 – S31, 2010\. \[Online\]\. Available:[http://www\.sciencedirect\.com/science/article/pii/S1742287610000319](http://www.sciencedirect.com/science/article/pii/S1742287610000319)
- \[20\]S\. Gopal, Y\. Yang, K\. Salomatin, and J\. Carbonell, “Statistical Learning for File\-Type Identification,” in*2011 10th International Conference on Machine Learning and Applications and Workshops*, vol\. 1\. IEEE, Dec\. 2011, pp\. 68–73, issue: DiiD\. \[Online\]\. Available:[http://ieeexplore\.ieee\.org/document/6146945/](http://ieeexplore.ieee.org/document/6146945/)
- \[21\]R\. Poisel and S\. Tjoa, “A Comprehensive Literature Review of File Carving,” in*2013 International Conference on Availability, Reliability and Security*\. IEEE, Sep\. 2013, pp\. 475–484\. \[Online\]\. Available:[http://ieeexplore\.ieee\.org/document/6657278/](http://ieeexplore.ieee.org/document/6657278/)
- \[22\]E\. Raff and C\. K\. Nicholas, “Lempel\-Ziv Jaccard Distance, an effective alternative to ssdeep and sdhash,”*Digital Investigation*, Feb\. 2018, arXiv: 1708\.03346\. \[Online\]\. Available:[https://doi\.org/10\.1016/j\.diin\.2017\.12\.004](https://doi.org/10.1016/j.diin.2017.12.004)
- \[23\]D\. Chang, M\. Ghosh, S\. K\. Sanadhya, M\. Singh, and D\. R\. White, “FbHash: A New Similarity Hashing Scheme for Digital Forensics,”*Digital Investigation*, vol\. 29, pp\. S113–S123, Jul\. 2019\. \[Online\]\. Available:[https://www\.sciencedirect\.com/science/article/pii/S1742287619301550](https://www.sciencedirect.com/science/article/pii/S1742287619301550)
- \[24\]E\. Raff and C\. Nicholas, “An Alternative to NCD for Large Sequences, Lempel\-Ziv Jaccard Distance,” in*Proceedings of the 23rd ACM SIGKDD International Conference on Knowledge Discovery and Data Mining \- KDD ’17*\. New York, New York, USA: ACM Press, 2017, pp\. 1007–1015\. \[Online\]\. Available:[http://dl\.acm\.org/citation\.cfm?doid=3097983\.3098111](http://dl.acm.org/citation.cfm?doid=3097983.3098111)
- \[25\]J\. Clemens, “Automatic classification of object code using machine learning,”*Digital Investigation*, vol\. 14, pp\. S156–S162, 2015\. \[Online\]\. Available:[http://www\.sciencedirect\.com/science/article/pii/S1742287615000523](http://www.sciencedirect.com/science/article/pii/S1742287615000523)
- \[26\]S\. Hand, Z\. Lin, G\. Gu, and B\. Thuraisingham, “Bin\-Carver: Automatic recovery of binary executable files,”*Digital Investigation*, vol\. 9, pp\. S108–S117, 2012\. \[Online\]\. Available:[http://www\.sciencedirect\.com/science/article/pii/S1742287612000394](http://www.sciencedirect.com/science/article/pii/S1742287612000394)
- \[27\]J\. van den Bos and T\. van der Storm, “Bringing Domain\-specific Languages to Digital Forensics,” in*Proceedings of the 33rd International Conference on Software Engineering*\. New York, NY, USA: ACM, 2011, pp\. 671–680, series Title: ICSE ’11\. \[Online\]\. Available:[http://doi\.acm\.org/10\.1145/1985793\.1985887](http://doi.acm.org/10.1145/1985793.1985887)
- \[28\]E\. F\. Wilgenbus, “The file fragment classification problem : A combined neural network and linear programming discriminant model approach,” Ph\.D\. dissertation, North\-West University, 2013, issue: April\. \[Online\]\. Available:[https://repository\.nwu\.ac\.za/handle/10394/10215](https://repository.nwu.ac.za/handle/10394/10215)
- \[29\]E\. Raff, W\. Fleshman, R\. Zak, H\. S\. Anderson, B\. Filar, and M\. McLean, “Classifying Sequences of Extreme Length with Constant Memory Applied to Malware Detection,” in*The Thirty\-Fifth AAAI Conference on Artificial Intelligence*, 2021, arXiv: 2012\.09390\. \[Online\]\. Available:[http://arxiv\.org/abs/2012\.09390](http://arxiv.org/abs/2012.09390)
- \[30\]E\. Raff, J\. Barker, J\. Sylvester, R\. Brandon, B\. Catanzaro, and C\. Nicholas, “Malware Detection by Eating a Whole EXE,” in*AAAI Workshop on Artificial Intelligence for Cyber Security*, oct 2018\. \[Online\]\. Available:[http://arxiv\.org/abs/1710\.09435](http://arxiv.org/abs/1710.09435)
- \[31\]L\. Sportiello and S\. Zanero, “File Block Classification by Support Vector Machine,” in*2011 Sixth International Conference on Availability, Reliability and Security*\. IEEE, Aug\. 2011, pp\. 307–312\. \[Online\]\. Available:[http://ieeexplore\.ieee\.org/document/6045955/](http://ieeexplore.ieee.org/document/6045955/)
- \[32\]J\. Xiong, C\. Jiang, Z\. Zhao, Y\. Qiao, N\. Zhang, M\. Feng, and X\. Wang, “Selecting the best fit software programming languages: Using bert for file format detection,”*Journal of Theory and Practice of Engineering Science*, vol\. 4, no\. 06, p\. 20–28, Jul\. 2024\. \[Online\]\. Available:[https://centuryscipub\.com/index\.php/jtpes/article/view/615](https://centuryscipub.com/index.php/jtpes/article/view/615)
- \[33\]M\. Schuster and K\. Nakajima, “Japanese and korean voice search,”*2012 IEEE International Conference on Acoustics, Speech and Signal Processing \(ICASSP\)*, pp\. 5149–5152, 2012\. \[Online\]\. Available:[https://api\.semanticscholar\.org/CorpusID:22320655](https://api.semanticscholar.org/CorpusID:22320655)
- \[34\]V\. Nair and G\. E\. Hinton, “Rectified Linear Units Improve Restricted Boltzmann Machines,”*Proceedings of the 27th International Conference on Machine Learning*, pp\. 807–814, 2010\.
- \[35\]D\.\-A\. Clevert, T\. Unterthiner, and S\. Hochreiter, “Fast and Accurate Deep Network Learning by Exponential Linear Units \(ELUs\),” in*Proceedings of the International Conference on Learning Representations \(ICLR\)*, 2016, arXiv: 1511\.07289\. \[Online\]\. Available:[http://arxiv\.org/abs/1511\.07289](http://arxiv.org/abs/1511.07289)
- \[36\]“Bigcode,” 2026\. \[Online\]\. Available:[https://huggingface\.co/bigcode](https://huggingface.co/bigcode)
- \[37\]D\. Kocetkov, R\. Li, L\. Ben Allal, J\. Li, C\. Mou, C\. Muñoz Ferrandis, Y\. Jernite, M\. Mitchell, S\. Hughes, T\. Wolf, D\. Bahdanau, L\. von Werra, and H\. de Vries, “The stack: 3 tb of permissively licensed source code,”*Preprint*, 2022\.
- \[38\]A\. Lozhkov, R\. Li, L\. B\. Allal, F\. Cassano, J\. Lamy\-Poirier, N\. Tazi, A\. Tang, D\. Pykhtar, J\. Liu, Y\. Wei, T\. Liu, M\. Tian, D\. Kocetkov, A\. Zucker, Y\. Belkada, Z\. Wang, Q\. Liu, D\. Abulkhanov, I\. Paul, Z\. Li, W\.\-D\. Li, M\. Risdal, J\. Li, J\. Zhu, T\. Y\. Zhuo, E\. Zheltonozhskii, N\. O\. O\. Dade, W\. Yu, L\. Krauß, N\. Jain, Y\. Su, X\. He, M\. Dey, E\. Abati, Y\. Chai, N\. Muennighoff, X\. Tang, M\. Oblokulov, C\. Akiki, M\. Marone, C\. Mou, M\. Mishra, A\. Gu, B\. Hui, T\. Dao, A\. Zebaze, O\. Dehaene, N\. Patry, C\. Xu, J\. McAuley, H\. Hu, T\. Scholak, S\. Paquet, J\. Robinson, C\. J\. Anderson, N\. Chapados, M\. Patwary, N\. Tajbakhsh, Y\. Jernite, C\. M\. Ferrandis, L\. Zhang, S\. Hughes, T\. Wolf, A\. Guha, L\. von Werra, and H\. de Vries, “Starcoder 2 and the stack v2: The next generation,” 2024\.
- \[39\]I\. Loshchilov and F\. Hutter, “Decoupled Weight Decay Regularization,” in*International Conference on Learning Representations \(ICLR\)*, 2019\. \[Online\]\. Available:[https://github\.com/loshchil/AdamW\-and\-SGDW](https://github.com/loshchil/AdamW-and-SGDW)
- \[40\]J\. Tompson, R\. Goroshin, A\. Jain, Y\. LeCun, and C\. Bregler, “Efficient object localization using Convolutional Networks,” in*2015 IEEE Conference on Computer Vision and Pattern Recognition \(CVPR\)*\. IEEE, Jun\. 2015, pp\. 648–656, arXiv: 1411\.4280v1\. \[Online\]\. Available:[http://ieeexplore\.ieee\.org/document/7298664/](http://ieeexplore.ieee.org/document/7298664/)
- \[41\]E\. Raff and C\. Nicholas, “A Survey of Machine Learning Methods and Challenges for Windows Malware Classification,” in*NeurIPS 2020 Workshop: ML Retrospectives, Surveys & Meta\-Analyses \(ML\-RSA\)*, 2020, arXiv: 2006\.09271\. \[Online\]\. Available:[http://arxiv\.org/abs/2006\.09271](http://arxiv.org/abs/2006.09271)