File Integrity Checksums

Checksums are used to verify the data integrity of a file, usually from automated processes and systems.

File checksums can be automatically calculated for files that are uploaded to your Files.com site.

You can select which types of checksum are generated for uploaded files. By default (after December 3rd, 2024), checksums are not generated for uploaded files.

Files.com supports generating checksums of types SHA256, SHA1, MD5, and CRC32. Each type of checksum can be enabled individually.

We recommend leaving checksums disabled unless your automated processes or users require them.

Checksums take time to compute and may not be immediately available when the upload completes. Larger files will take longer to have their checksums computed than smaller files.

File upload performance is slightly improved when checksums are disabled.

Viewing Checksum Information

Within our web portal, you can view checksum information in the metadata panel by selecting or previewing a file.

Checksum information can also be viewed and accessed using our Command Line Integration (CLI) App, our SDKs, and our file object API.

Legacy Checksum Mode

Prior to December 3rd, 2024, only generation of MD5 and CRC checksums were supported. These checksums were automatically calculated for all files uploaded to Files.com storage regions. There were no options to specify which checksum types to generate or exclude.

MD5 and CRC file checksums generated prior to December 3rd, 2024 were preserved and retained.

Do I Need A Checksum?

Checksums detect whether a file's contents changed during transmission.

Most users will never use a checksum themselves. Some automated processes compare a file's checksum before and after a transmission to confirm the file arrived intact before continuing to process it.

If your automated business processes rely on a checksum for verifying file integrity, enable the corresponding checksum type for your Files.com site.

Checksum Exchange With a Partner

A checksum is a digest calculated from a file's contents. The sender calculates it from the completed source file; the receiver calculates it independently from the delivered file. Matching values provide evidence that the bytes match. A checksum does not establish who supplied the file or whether its business records are correct.

Both sides must use the same algorithm and the same bytes. SHA256 and MD5 values for one file will differ. Changes to line endings, character encoding, compression, or encryption also change the bytes. Agree whether the checksum describes the original CSV, the compressed package, or the encrypted file, and compare it at that stage. Prefer SHA256 for a new exchange when both systems support it; use a partner-required legacy algorithm for the compatibility requirement it serves.

The sender can provide a separate checksum file, often called a sidecar, alongside the data. For example, invoices.csv.sha256 can identify the expected SHA256 digest for invoices.csv. Agree on the sidecar's format and filename, and publish it only after the corresponding data is complete. A readiness signal or manifest can coordinate a batch containing both.

On Linux with GNU tools, generate a SHA256 sidecar from the completed source file:

sha256sum invoices.csv > invoices.csv.sha256

After receiving both files, run this command in their directory to calculate the received file's checksum and compare it with the sidecar:

sha256sum --check invoices.csv.sha256

On macOS, use shasum to create and check the same style of sidecar:

shasum -a 256 invoices.csv > invoices.csv.sha256
shasum -a 256 --check invoices.csv.sha256

In Windows PowerShell, calculate the file's SHA256 value with:

Get-FileHash -Algorithm SHA256 -LiteralPath .\invoices.csv

Compare the full Hash value with the partner's expected SHA256 digest. Hexadecimal letter case does not change the value. For automated comparison, follow the agreed sidecar format rather than treating an arbitrary text file as a checksum file.

Obtain the expected checksum through the agreed trusted exchange. Replacing both a data file and its unsigned checksum can preserve a match. If the recipient must verify the sender's identity as well as the bytes, use the agreed digital-signature verification, with a trusted signing key.

A remote object's ETag is not a universal file checksum. In object storage it can depend on the upload method or service, including multipart upload. Compare an explicitly identified checksum rather than assuming an ETag is an MD5 value.

Checksum Limitations

Checksums are only generated for files that are uploaded to any of the Files.com storage regions. Checksums are not generated for files that are uploaded to mounted remote servers.

Checksums are only generated for files smaller than 250 GB in size (the limit is 10GB if you have not manually enabled checksums and are instead relying on the legacy default choice of MD5 and CRC32). If you require checksums for larger files, please contact us to discuss your size requirements.