# mzML Conversion in Proteomics: Best Practices for Reliable Data Sharing and Analysis

Mass spectrometry proteomics laboratories face a persistent interoperability problem: vendor-specific binary files cannot be read by most open-source analysis tools, and researchers must convert these files to the open mzML format before downstream processing. The conversion step is not trivial, and incorrect parameter choices can silently degrade spectral quality, inflate file sizes, slow downstream analysis, or introduce quantitative bias. This article provides a practical framework for converting proprietary raw mass spectrometry data to mzML using msconvert, ThermoRawFileParser, and related tools, with specific attention to parameter selection, quality verification, reproducibility, and common failure modes. The guidance is intended for biology students, researchers, laboratory professionals, and life-science practitioners who need defensible, shareable data conversion workflows.

## Scope and Reader Context

This article addresses the specific problem of converting proprietary mass spectrometry raw files to the open mzML format without data loss or unintended alteration. The target reader is a researcher or laboratory professional who has access to vendor raw files, needs to use cross-platform analysis tools, and must decide which conversion tool and parameters to use. The scope covers the main conversion tools, parameter recommendations, file size and compression considerations, quality control checks, and documentation practices. The article does not cover instrument operation, experimental design, or downstream statistical analysis in depth, though it references these topics where they intersect with conversion decisions.

The practical outcome is a defensible conversion workflow that produces mzML files suitable for public repositories, collaborative analysis, and reproducible research. The guidance emphasizes verification steps that confirm the converted files retain the information needed for protein identification and quantification.

## Why mzML Conversion Matters for Proteomics Workflows

Mass spectrometry instruments from different manufacturers store data in proprietary binary formats that are tightly coupled to vendor software libraries. These formats are efficient for the instrument software but create barriers for the broader bioinformatics ecosystem. Most cross-platform proteomics tools cannot operate directly on proprietary formats generated by diverse mass spectrometers, so conversion to an open format is the first step in many analysis protocols. The mzML format, developed under the HUPO-PSI standards process, serves as the common interchange format that enables platform-independent analysis software to process data from any instrument vendor.

The conversion process itself must occur on a platform where the vendor libraries are available, which typically means Windows for Thermo, Bruker, and SCIEX instruments. Once mzML files have been generated, they can be used on any platform, including Linux clusters and cloud infrastructure. This platform dependency at the conversion step is a practical constraint that laboratories must plan for when designing their data processing pipelines.

The stakes of conversion quality are high. If the conversion drops important metadata, miscalculates peak intensities, or applies inappropriate compression, downstream protein identification and quantification results can be compromised. Unlike a simple file format change, mzML conversion involves decoding vendor-specific data structures, interpreting instrument parameters, and re-encoding spectral data into a standardized XML schema. Each of these steps carries the risk of subtle information loss that may not be immediately visible to the researcher.

## Core Principles of Reliable mzML Conversion

### Preserve Spectral Fidelity

The primary goal of conversion is to preserve the information content of the original raw file. This includes precursor masses, fragment ion masses, intensities, retention times, charge states, and instrument metadata. A reliable conversion should not alter the underlying measurements, only the encoding. When quantitative proteomics is the downstream goal, the converted file must support reliable quantitative results comparable to what the vendor software would produce.

### Maintain Metadata Completeness

mzML files contain also spectral data but also instrument configuration, sample information, and acquisition parameters. This metadata is essential for interpreting results, reproducing experiments, and meeting repository submission requirements. Conversion tools differ in how completely they transfer vendor-specific metadata into the standardized mzML structure. Researchers should verify that critical metadata fields survive the conversion process.

### Balance File Size Against Accessibility

The mzML format is text-based XML, which is less efficient than vendor binary formats. Naive mzML representations can be fourfold or even up to 18-fold larger than the original vendor file. In disk I/O limited setups, larger data files lead to longer processing times, which is a problem given the data production rates of modern mass spectrometers. Compression options, including the MS-Numpress algorithms and general-purpose compression like gzip, can reduce file sizes dramatically, but they add computational overhead and may affect random access patterns.

### Ensure Reproducibility Through Documentation

Conversion parameters must be recorded and reported alongside the converted files. Different tools and parameter combinations can produce different mzML outputs from the same raw file. Without documentation, collaborators and reviewers cannot assess whether the conversion was appropriate or reproduce the conversion themselves. Version numbers for both the conversion tool and the vendor libraries should be captured in the analysis records.

## At a Glance: Conversion Tool Comparison

| Tool | Platform Support | Key Strengths | Primary Limitation | Best Use Case |
|------|------------------|---------------|-------------------|---------------|
| msconvert (ProteoWizard) | Windows required for vendor library access, output usable anywhere | Extensive format support, many parameter options, widely documented | Parameter choices require expertise, vendor library dependencies | Standard laboratory conversion with full parameter control |
| ThermoRawFileParser | Cross-platform including Linux and cloud | Modular design, Conda and BioContainers packaging, GUI available | Thermo RAW files only, fewer format options than msconvert | High-throughput Thermo data on Linux clusters or Galaxy/Nextflow workflows |
| mineXpert2 | Cross-platform after mzML conversion | Full-depth MS(n) visualization, no vendor software needed after conversion | Requires mzML input, not a conversion tool itself | Visual verification of converted data quality |

The choice of conversion tool depends on the instrument vendor, the computing environment, and the downstream analysis platform. For Thermo instruments, both msconvert and ThermoRawFileParser produce reliable mzML files with comparable quantitative results. For other vendors, msconvert is the primary option because it supports the broadest range of proprietary formats.

## Practical Conversion Workflow

### Step 1: Inventory Your Raw Files and Instrument Metadata

Before starting conversion, document the complete set of raw files to be converted, including the instrument type, acquisition method, and any relevant experimental design information. This inventory serves as the reference against which you verify the completeness of the converted files. Record the vendor software version used to acquire the data, as this can affect how the raw file is structured and how the conversion tool interprets it.

### Step 2: Select the Appropriate Conversion Tool

For most laboratories, msconvert from ProteoWizard is the default choice because it supports the widest range of vendor formats and offers the most comprehensive parameter options. The msConvertGUI provides a graphical interface for those who prefer not to work with command-line tools, while the command-line version enables scripting and batch processing. For Thermo RAW files processed on Linux or cloud infrastructure, ThermoRawFileParser offers a cross-platform alternative that integrates with workflow systems such as Galaxy and Nextflow through Conda packages and BioContainers.

### Step 3: Configure Conversion Parameters

The parameter choices made during conversion have direct consequences for file size, processing speed, and downstream analysis compatibility. The following parameters require explicit decisions:

**Peak Picking:** The choice between converting profile data or centroided data is the most consequential decision. Profile data retains the full shape of each peak, which is necessary for certain types of analysis but produces much larger files. Centroided data reduces each peak to its monoisotopic mass and intensity, which is sufficient for most identification and quantification workflows. If the vendor software has already centroided the data during acquisition, no additional peak picking is needed. If you are converting profile data, you must decide whether to apply peak picking during conversion or preserve the profile data for later processing.

**Compression:** The mzML format supports binary data compression using the MS-Numpress algorithms, which are designed specifically for mass spectrometry data. These algorithms target the binary data in the mzML standard and are supported in main proteomics tools. Typical file size decreases of 90% are achievable when MS-Numpress compression is combined with traditional compression, with read time decreases of up to 50%. The choice of compression algorithm depends on the data type: different algorithms are optimized for m/z values, intensities, and retention times.

**Filtering:** msconvert supports various filters that can remove low-quality spectra, select specific scan types, or restrict the m/z range. These filters reduce file size but also remove information. Apply filters only when you have a specific analytical reason and document the filter parameters in your records.

**Metadata Inclusion:** Some conversion tools allow you to strip metadata to reduce file size. This practice is strongly discouraged for public data sharing because metadata is essential for interpretation and reproducibility.

### Step 4: Execute the Conversion

Run the conversion in batch mode where possible, processing all files in an experiment with identical parameters. This consistency is essential for downstream comparative analysis. Monitor the conversion log for warnings or errors, and verify that each input file produces a corresponding output file of reasonable size.

### Step 5: Verify Converted File Quality

Quality verification is the step most often skipped and the step most likely to catch problems. At minimum, verify the following for each converted file:

- The file opens without errors in a viewer or analysis tool
- The number of spectra in the mzML file matches the number in the raw file
- Total ion current and base peak intensities are comparable between raw and converted files
- Retention time ranges match
- Precursor masses for MS/MS spectra match the expected values

For Thermo files, a benchmark comparison of ThermoRawFileParser and msconvert has verified that converted mzML files contain reliable quantitative results, so either tool can be trusted for quantitative work when configured correctly.

### Step 6: Document the Conversion Process

Create a conversion record that includes the tool name and version, vendor library versions, all parameter settings, the date of conversion, and the person who performed the conversion. This record should be stored with the converted files and referenced in any publication or repository submission. The record enables others to reproduce the conversion and assess whether the parameters were appropriate for their intended use.

## Options and Tradeoffs in Conversion Tools

### msconvert and ProteoWizard

The ProteoWizard msConvert software is the most widely used conversion tool in proteomics. Its protocol documentation describes the various options available when doing conversions and the implications of each option. The tool handles format features, coding options, and vendor particularities, making it suitable for data from most major instrument manufacturers. The graphical interface lowers the barrier for new users, while the command-line interface supports automation and batch processing.

The main limitation of msconvert is that it requires the vendor libraries to be available on the conversion platform, which typically means Windows. This constraint is manageable for laboratories with Windows workstations but creates friction for groups that want to process data entirely on Linux or cloud infrastructure.

### ThermoRawFileParser

ThermoRawFileParser was developed specifically to address the need for cross-platform conversion of Thermo RAW files. It is open source, modular, and scalable, making it suitable for high-throughput environments. The tool is packaged as a Conda package and a BioContainers container, which simplifies integration with popular workflow systems such as Galaxy and Nextflow. A graphical interface is available for users who prefer not to use the command line.

The benchmark comparison with msconvert confirmed that ThermoRawFileParser produces mzML files with reliable quantitative results. This makes it a defensible choice for Thermo data, particularly in Linux-based cluster environments and cloud infrastructures where msconvert cannot run.

### Specialized Tools and Formats

Beyond the standard mzML conversion tools, the proteomics community has developed specialized formats and encoding schemes that address the file size and speed limitations of mzML. The Stack-ZDPD encoding scheme, designed for the Aird computation-oriented format, reduces the volume of data stored in mzML format by around 80% or more, depending on the data acquisition pattern. For data generated using Time of Flight technology, the compression ratio is approximately 30% compared to the ZDPD algorithm alone. These specialized formats are available through AirdPro for file conversion and the Java-API Aird-SDK for data parsing.

These alternative formats are appropriate when storage space or read speed is the primary constraint and when the downstream analysis tools support the format. For standard proteomics workflows and public repository submissions, mzML remains the expected format.

## Observations and Measurements for Conversion Quality

### File Size as a Diagnostic Indicator

File size is the first indicator of conversion problems. If the mzML file is unexpectedly small, the conversion may have dropped spectra or applied overly aggressive filtering. If the file is unexpectedly large, compression may not have been applied or the conversion may have duplicated data. Compare the size of the mzML file to the size of the original raw file and to mzML files from similar experiments to establish expected size ranges.

The relationship between raw file size and mzML file size depends on the instrument type, acquisition mode, and compression settings. Naive mzML representations can be fourfold or even up to 18-fold larger than the original vendor file. With MS-Numpress compression combined with traditional compression, typical file size decreases of 90% are achievable. A converted file that does not show this level of compression may have been converted without compression enabled.

### Spectral Count Verification

The number of spectra in the converted file should match the number in the raw file. This count is available from the vendor software and from the mzML file header. Discrepancies indicate that spectra were dropped during conversion, which can happen when filters are applied incorrectly or when the conversion tool encounters scan types it does not recognize.

### Intensity and Retention Time Consistency

For a random sample of spectra, compare the precursor masses, fragment ion masses, intensities, and retention times between the raw file and the converted file. The vendor software can display this information for the raw file, and any mzML viewer can display it for the converted file. Small differences in intensity values can result from different peak picking algorithms, but large differences indicate a conversion problem.

### Quantitative Benchmarking

For quantitative experiments, run a small-scale comparison between the vendor software analysis and the converted mzML analysis. The quantitative results should be comparable. This benchmarking step is particularly important when switching conversion tools or changing parameter settings, because it verifies that the conversion does not introduce quantitative bias.

## Records and Documentation Requirements

### Conversion Log

Maintain a conversion log that records the following for each batch of files:

- Tool name and version
- Vendor library versions
- All parameter settings, including peak picking, compression, and filtering options
- Date and time of conversion
- Operator name
- Input file names and checksums
- Output file names and checksums
- Any warnings or errors generated during conversion

### File Naming Convention

Use a consistent file naming convention that preserves the relationship between raw files and converted files. Include the instrument type, acquisition date, sample identifier, and conversion tool in the file name or in an accompanying manifest. This convention prevents confusion when multiple versions of the same data exist.

### Repository Submission Records

When submitting mzML files to public repositories, include the conversion parameters in the submission metadata. Repositories such as those maintained by NCBI and EMBL-EBI have specific requirements for data submission, and documenting the conversion process is part of responsible data sharing. The NCBI data resources provide official descriptions of database submission requirements, and EMBL-EBI training materials cover data submission best practices.

## Common Failure Patterns in mzML Conversion

### Silent Data Loss Through Filtering

The most dangerous failure pattern is silent data loss through incorrect filter configuration. A filter that removes low-intensity spectra or restricts the m/z range can eliminate data that is essential for downstream analysis. The conversion completes without errors, and the researcher does not discover the loss until the analysis results are unexpectedly incomplete.

**Prevention:** Apply filters only when you have a specific analytical reason. Document the filter parameters and verify spectral counts before and after conversion.

### Inappropriate Compression Settings

Compression settings that do not match the data type can produce files that are larger than necessary or, in rare cases, files that cannot be read by downstream tools. The MS-Numpress algorithms are designed for specific data types, and using the wrong algorithm for a particular binary array can reduce compression efficiency or produce incorrect values.

**Prevention:** Use the compression settings recommended by the conversion tool documentation and verify that downstream tools can read the compressed files.

### Metadata Stripping

Some conversion workflows strip metadata to reduce file size. This practice removes information needed for interpretation and reproducibility. The resulting files may be smaller, but they are less useful for collaborative analysis and repository submission.

**Prevention:** Preserve all metadata during conversion. If file size is a concern, use compression instead of metadata removal.

### Version Mismatches

Conversion tools and vendor libraries are updated regularly, and different versions can produce different output from the same input file. A file converted with an older version of msconvert may differ from a file converted with a newer version, even when the parameters are identical.

**Prevention:** Record the exact versions of all software used in the conversion. When comparing files from different experiments, verify that the same conversion environment was used.

### Platform-Specific Vendor Library Issues

The requirement for vendor libraries to be available on the conversion platform creates a failure mode where the conversion tool cannot read certain files because the vendor library version does not match the file format version. This problem is more common when files are acquired on newer instruments and converted with older library versions.

**Prevention:** Keep vendor libraries updated and test conversion on a small sample of files before processing a full batch.

## Limitations of mzML Conversion

### Platform Dependency at Conversion Time

The conversion from vendor formats to mzML must take place on a platform on which the vendor libraries are available, which typically means Windows. This constraint limits the ability to process data entirely on Linux or cloud infrastructure, although tools like ThermoRawFileParser mitigate this limitation for Thermo data.

### File Size and Processing Speed

The mzML format is less efficient than vendor formats, and larger data files lead to longer processing times in disk I/O limited setups. This is a problem given the data production rates of modern mass spectrometers. Compression algorithms reduce the file size but add computational overhead during conversion and decompression.

### Loss of Vendor-Specific Features

Some vendor-specific data features do not map cleanly to the mzML schema. These features may be stored in vendor-specific extensions or may be lost during conversion. Researchers who rely on these features must verify that the mzML file retains the information they need.

### Interpretation Limits

The mzML format standardizes the data structure but does not standardize the interpretation of the data. Different analysis tools may interpret the same mzML file differently, particularly for complex data types such as ion mobility mass spectrometry. The mzML file is a faithful representation of the instrument output, but it does not guarantee that all downstream tools will extract the same information.

## Quality Control and Verification Protocols

### Automated Quality Checks

Implement automated quality checks that run immediately after conversion and flag files that do not meet expected criteria. These checks can include:

- File size within expected range
- Spectral count matches the raw file
- Required metadata fields are present
- File opens without errors in a test tool

Automated checks are particularly valuable for high-throughput conversion where manual verification of every file is impractical.

### Manual Verification for Critical Files

For files that will be used in publications or submitted to repositories, perform manual verification using a visualization tool. mineXpert2 provides full-depth visualization and exploration of MS(n) mass spectrometry data and requires no proprietary software after conversion to mzML. This tool allows the researcher to inspect spectra, verify peak shapes, and confirm that the converted data retains the expected features.

### Benchmark Comparisons

When changing conversion tools or parameters, run a benchmark comparison on a representative subset of files. Compare the quantitative results from the vendor software to the results from the converted mzML files. This comparison verifies that the conversion does not introduce bias and provides evidence for the reliability of the conversion workflow.

## Safety and Regulatory Context for Data Handling

### Data Integrity for Regulatory Submissions

For laboratories operating under regulatory frameworks, the conversion process must preserve data integrity and provide an audit trail. The conversion log serves as this audit trail, documenting who converted the data, when, and with what parameters. Regulatory submissions may require evidence that the conversion process does not alter the underlying measurements.

### Data Sharing and Reproducibility Requirements

Funding agencies and journals increasingly require that proteomics data be deposited in public repositories in open formats. The mzML format is the expected format for these submissions, and the conversion parameters must be documented to enable others to assess the data quality. The NCBI data resources and EMBL-EBI training materials provide guidance on data submission requirements and best practices.

### Data Retention Policies

Laboratories should establish data retention policies that specify how long raw files and converted files are kept. Raw files are the primary record of the experiment and should be retained for the full retention period. Converted files can be regenerated from raw files, but the conversion parameters should be retained to enable regeneration.

## Professional Escalation Criteria

### When to Consult a Bioinformatics Specialist

Seek expert assistance when any of the following situations arise:

- The conversion tool reports errors that you cannot resolve through parameter adjustment
- The converted files fail quality checks and the cause is not apparent
- You need to convert data from an instrument type or vendor format that is not covered by your standard workflow
- The downstream analysis tools require specific mzML features that your conversion does not produce
- You are setting up a new high-throughput conversion pipeline and need guidance on best practices

### When to Contact the Tool Developers

Contact the tool developers when you encounter behavior that appears to be a bug or when the documentation does not cover your use case. Include the tool version, the vendor file format, and a minimal example that reproduces the problem. The developers of msconvert, ThermoRawFileParser, and related tools are responsive to user reports and can provide guidance on unusual data types.

### When to Escalate to the Instrument Vendor

Escalate to the instrument vendor when the conversion problem appears to originate in the vendor file format or the vendor libraries. This situation is more common with newly released instruments or acquisition software versions. The vendor may need to update their libraries to support the conversion tools.

## Training and Skill Development for Conversion Workflows

### Foundational Computing Skills

Reliable mzML conversion requires basic command-line skills, file management, and scripting abilities. The Carpentries lessons provide foundational training in shell, Git, and programming that is directly applicable to building conversion workflows. These skills enable researchers to automate conversion, document parameters, and verify outputs systematically.

### Bioinformatics Training Pathways

The EMBL-EBI training program offers learning pathways for bioinformatics data resources and practical analysis education. These training materials cover data formats, conversion tools, and analysis workflows that are relevant to mzML conversion. Researchers new to proteomics bioinformatics should complete these training modules before attempting complex conversion workflows.

### Workflow-Specific Training

The Galaxy Training Network provides accessible workflow training and analysis tutorials that include mass spectrometry data processing. These tutorials demonstrate how to integrate mzML conversion into larger analysis pipelines and how to ensure reproducibility. The nf-core documentation describes community pipeline standards and usage patterns that are relevant for laboratories adopting Nextflow-based workflows.

## Building a Reproducible Conversion Pipeline

### Containerization and Package Management

Containerization ensures that the conversion environment is identical across different machines and time points. ThermoRawFileParser is available as a BioContainers container, and msconvert can be containerized using standard approaches. Containers capture the tool version, vendor library versions, and system dependencies, making the conversion reproducible.

### Workflow Management Systems

Workflow management systems such as Galaxy and Nextflow provide structured environments for running conversion pipelines. These systems track the inputs, outputs, and parameters of each step, creating an automatic audit trail. The Galaxy Training Network and nf-core documentation provide guidance on building and running these workflows.

### Version Control for Conversion Scripts

Store conversion scripts and parameter files in a version control system. This practice enables you to track changes to the conversion process over time and to reproduce the exact conversion used for a particular dataset. The Carpentries lessons cover Git fundamentals that are sufficient for this purpose.

## Integration with Downstream Analysis Tools

### Compatibility with Identification Software

Most protein identification tools accept mzML input, but they may have specific requirements for peak picking, compression, or metadata. Verify that the mzML files produced by your conversion workflow are compatible with the identification software used in your laboratory. This verification should be part of the initial pipeline setup and should be repeated when either the conversion tool or the identification software is updated.

### Compatibility with Quantification Software

Quantitative proteomics tools have stricter requirements for data quality because quantification depends on accurate intensity measurements. The benchmark comparisons between conversion tools have verified that both msconvert and ThermoRawFileParser produce mzML files with reliable quantitative results for Thermo data. For other instrument types, perform similar benchmark comparisons to verify quantitative reliability.

### Compatibility with Visualization Tools

Visualization tools such as mineXpert2 require mzML input and provide full-depth visualization and exploration of MS(n) data. These tools are useful for manual quality verification and for exploring data in ways that vendor software may not support. After conversion to mzML, these tools require no proprietary software whatsoever.

## Data Management for Large-Scale Conversion Projects

### Batch Processing Strategies

For large-scale conversion projects, develop a batch processing strategy that includes:

- A manifest of all files to be converted
- A standardized parameter file
- Automated quality checks after conversion
- A logging system that captures conversion results

This strategy ensures consistency across the batch and simplifies troubleshooting when problems arise.

### Storage Planning

Plan storage capacity based on the expected mzML file sizes. With MS-Numpress compression, mzML files are typically smaller than naive representations but may still be larger than the original vendor files. The file size decreases of 90% achievable with MS-Numpress combined with traditional compression make storage planning more predictable.

### Backup and Archival

Maintain backup copies of both raw files and converted files. The raw files are the primary record and cannot be regenerated if lost. The converted files can be regenerated from raw files, but the conversion parameters must be preserved to enable regeneration.

## Troubleshooting Common Conversion Problems

### Problem: Converted File Is Much Larger Than Expected

Check whether compression was enabled during conversion. The mzML format without compression can be fourfold or even up to 18-fold larger than the original vendor file. Enable MS-Numpress compression combined with traditional compression to achieve typical file size decreases of 90%.

### Problem: Converted File Is Much Smaller Than Expected

Check whether filters were applied that removed spectra or restricted the m/z range. Verify the spectral count in the converted file against the raw file. If spectra were dropped, reconvert without the problematic filters.

### Problem: Downstream Tools Cannot Read the Converted File

Check whether the compression algorithm used is supported by the downstream tool. Some tools have limited support for certain compression algorithms. Reconvert with a more widely supported compression setting or verify the tool version.

### Problem: Quantitative Results Differ Between Vendor Software and mzML Analysis

Check whether peak picking was applied consistently. Different peak picking algorithms can produce different intensity values. Verify that the conversion parameters match the vendor software settings and consider benchmarking the conversion against a known standard.

### Problem: Metadata Is Missing from the Converted File

Check whether the conversion tool preserved the metadata. Some tools have options to strip metadata, and these options may be enabled by default in certain configurations. Reconvert with metadata preservation enabled.

## Professional Escalation Criteria

### When to Seek Expert Assistance

Seek expert assistance when the conversion problem affects data that will be used in publications or regulatory submissions, when the problem persists after troubleshooting, or when the conversion workflow needs to be modified for a new instrument type or data format. Bioinformatics specialists can provide guidance on parameter selection, quality verification, and workflow design.

### When to Report Issues to Tool Developers

Report issues to tool developers when you have identified a reproducible problem that appears to be a bug. Provide the tool version, the vendor file format, and a minimal example that reproduces the problem. This information enables the developers to diagnose and fix the issue.

### When to Escalate to the Instrument Vendor

Escalate to the instrument vendor when the conversion problem appears to originate in the vendor file format or the vendor libraries. This situation is more common with newly released instruments or acquisition software versions. The vendor may need to update their libraries to support the conversion tools.

## Frequently Asked Questions

### What is the difference between profile data and centroided data in mzML conversion?

Profile data preserves the full shape of each peak, including the continuous signal across the m/z range. Centroided data reduces each peak to a single data point representing the monoisotopic mass and intensity. Profile data produces much larger files but retains information that may be needed for certain types of analysis. Centroided data is sufficient for most identification and quantification workflows and produces smaller files. The choice between profile and centroided data should be made based on the downstream analysis requirements.

### Which conversion tool should I use for Thermo RAW files?

Both msconvert from ProteoWizard and ThermoRawFileParser produce reliable mzML files from Thermo RAW files. A benchmark comparison has verified that both tools produce mzML files with reliable quantitative results. The choice depends on your computing environment. If you are working on Windows, msconvert is a solid choice. If you need to process data on Linux or cloud infrastructure, ThermoRawFileParser is the better option because it is cross-platform and available as a Conda package and BioContainers container.

### How much smaller will my mzML files be with compression?

The MS-Numpress compression algorithms, when combined with traditional compression, achieve typical file size decreases of 90% compared to uncompressed mzML. The actual compression ratio depends on the data type and acquisition pattern. Without compression, mzML files can be fourfold or even up to 18-fold larger than the original vendor file. Compression also reduces read times by up to 50% in disk I/O limited setups.

### Can I convert mzML files on a Linux computer?

The conversion from vendor formats to mzML must take place on a platform where the vendor libraries are available, which typically means Windows. However, once mzML files have been generated, they can be used on any platform. ThermoRawFileParser is an exception because it is cross-platform and can convert Thermo RAW files on Linux. For other vendors, you will need access to a Windows machine for the conversion step.

### What quality checks should I perform after conversion?

At minimum, verify that the file opens without errors, the number of spectra matches the raw file, total ion current and base peak intensities are comparable, retention time ranges match, and precursor masses for MS/MS spectra match expected values. For quantitative experiments, run a small-scale comparison between the vendor software analysis and the converted mzML analysis to verify that quantitative results are comparable.

### Why is my converted file much larger than the original raw file?

The mzML format is text-based XML, which is less efficient than vendor binary formats. Without compression, mzML representations can be fourfold or even up to 18-fold larger than the original vendor file. Enable MS-Numpress compression combined with traditional compression to reduce file sizes by approximately 90%.

### What metadata should I preserve during conversion?

Preserve all metadata that describes the instrument configuration, sample information, and acquisition parameters. This metadata is essential for interpreting results, reproducing experiments, and meeting repository submission requirements. Some conversion tools offer options to strip metadata to reduce file size, but this practice is strongly discouraged for public data sharing.

### How do I document the conversion process for reproducibility?

Record the tool name and version, vendor library versions, all parameter settings, the date of conversion, and the person who performed the conversion. Store this record with the converted files and reference it in any publication or repository submission. This documentation enables others to reproduce the conversion and assess whether the parameters were appropriate for their intended use.

## Related Bioinformatics Guides

- [Genomic Data Analysis Tools: A Comparative Guide for Researchers](/knowledge/bioinformatics/genomic-data-analysis-tools-a-comparative-guide-for-researchers)
- [Mass Spectrometry-Based Proteomics: Data Analysis Pipelines and Tools](/knowledge/bioinformatics/mass-spectrometry-based-proteomics-data-analysis-pipelines-and-tools)
- [Proteomics Data Analysis Workflow: From Raw Spectra to Biological Insights](/knowledge/bioinformatics/proteomics-data-analysis-workflow-from-raw-spectra-to-biological-insights)
- [Genomic Data Processing: From Raw Sequencing to Analysis-Ready Files](/knowledge/bioinformatics/genomic-data-processing-from-raw-sequencing-to-analysis-ready-files)
- [Pathway Enrichment Analysis for Proteomics: Tools and Interpretation](/knowledge/bioinformatics/pathway-enrichment-analysis-for-proteomics-tools-and-interpretation)

## References and Further Reading

- [NCBI Data Resources](https://www.ncbi.nlm.nih.gov/). National Center for Biotechnology Information.
- [EMBL-EBI Training](https://www.ebi.ac.uk/training). European Bioinformatics Institute.
- [Bioconductor](https://bioconductor.org/). Bioconductor Project.
- [Galaxy Training Network](https://training.galaxyproject.org/). Galaxy Project.
- [nf-core Documentation](https://nf-co.re/docs). nf-core.
- [The Carpentries Lessons](https://carpentries.org/lessons). The Carpentries.
- [Numerical compression schemes for proteomics mass spectrometry data.](https://pubmed.ncbi.nlm.nih.gov/24677029). Molecular & cellular proteomics : MCP, 2014.
- [Data Conversion with ProteoWizard msConvert.](https://pubmed.ncbi.nlm.nih.gov/28188540). Methods in molecular biology (Clifton, N.J.), 2017.
- [ThermoRawFileParser: Modular, Scalable, and Cross-Platform RAW File Conversion.](https://pubmed.ncbi.nlm.nih.gov/31755270). Journal of proteome research, 2020.
- [StackZDPD: a novel encoding scheme for mass spectrometry data optimized for speed and compression ratio.](https://pubmed.ncbi.nlm.nih.gov/35354909). Scientific reports, 2022.
- [mineXpert2: Full-Depth Visualization and Exploration of MS(n) Mass Spectrometry Data.](https://pubmed.ncbi.nlm.nih.gov/33683899). Journal of the American Society for Mass Spectrometry, 2021.

> This article is educational and does not replace validated analysis plans, institutional policy, clinical interpretation, or specialist review.