You create a PDF Portfolio containing five documents. On your Windows computer, the portfolio file properties show a size of 12 megabytes. You transfer the same file to a Mac, and the Finder reports 15 megabytes. You open it on a Linux machine, and the file manager shows 10 megabytes. The file is identical. The reported size varies because different operating systems calculate file size differently.
File size reporting differences between operating systems are a common source of confusion. The actual number of bytes in the file is the same everywhere. What differs is how the operating system converts bytes to kilobytes, megabytes, or gigabytes for display.
Why Operating Systems Report Different File Sizes
The root cause is the binary vs decimal unit confusion. Computers store files in bytes, which are counted in powers of two. A kilobyte in binary is 1024 bytes. A megabyte is 1024 kilobytes, or 1,048,576 bytes. Apple macOS and Linux report file sizes using these binary units.
Microsoft Windows reports file sizes using decimal units, where a kilobyte is 1000 bytes and a megabyte is 1,000,000 bytes. The same file shows a larger number of decimal kilobytes than binary kilobytes because the decimal unit is smaller. A file that is 1,048,576 bytes shows as 1,024 KB in Windows decimal display but as 1,024 KB or 1 MB in macOS binary display.
The root cause is simpler than most people expect.
The PDF File Size discrepancy is most noticeable with larger files. A 100-megabyte file in Windows decimal units is approximately 95 megabytes in macOS binary units. The 5 percent difference is enough to cause confusion when comparing file sizes across platforms.
Other Factors That Affect Reported File Size
Cloud storage services may report a different file size than the local file system because the service compresses or deduplicates the file in storage. The size shown in the cloud interface is the storage size after optimization, not the original file size.
File compression applied by the file system, such as NTFS compression on Windows or APFS compression on macOS, reduces the disk space used but does not change the reported file size. The reported size is the uncompressed size of the file.
The PDF Viewing software may also report a different size in its document properties panel. Some PDF readers calculate the size of the decompressed content rather than the compressed file size. The document properties size and the file system size can differ significantly.
Verifying the Actual File Size
Check the exact byte count of the file, which is the same on every operating system. In Windows, right-click the file, select Properties, and read the Size value in bytes. On macOS, select the file and choose Get Info. On Linux, use the ls -l command. The byte count is the ground truth.
When sharing file size specifications with colleagues on different operating systems, specify the unit and the counting method. A 10 MB file in Windows may be a 9.5 MB file on macOS. Clarifying avoids confusion.
Practical Implications of File Size Discrepancies
A client reports that a file you sent is a different size than expected, the unit difference is the most likely explanation. Before assuming file corruption or transmission errors, confirm whether both parties are using the same unit definition. A quick byte count comparison resolves the confusion.
Email attachment size limits are typically specified in decimal megabytes by the email service provider. A 25 MB limit in Gmail means 25 million bytes. A file that reports as 25 MB in Windows decimal units is at the limit. The same file reporting as 23.8 MB on macOS would appear safely under the limit.
File transfer services that display upload progress may show a different file size than the local file system because they calculate the transfer size including protocol overhead. The additional bytes for transfer encoding can add several percent to the apparent file size during upload.
Normalizing File Size Reporting Across Platforms
When documenting file size specifications for a team or client project, specify the file size in bytes and the unit used for display. A specification that reads 10,485,760 bytes (10 MB Windows, 10 MiB macOS) eliminates ambiguity and prevents the recurring confusion of mismatched file size reports.
WukongPDF processes PDF portfolios and individual files through the browser, displaying consistent file size information regardless of the operating system. This consistency helps teams working across different platforms avoid the file size confusion described here.
Cloud storage services that show file size in their web interfaces typically use the same unit system as the server operating system, which is usually Linux and therefore binary units. A file uploaded from Windows may appear to shrink when viewed in the cloud interface because the display units changed.
For document management and archival purposes, record the byte count of each file in the document metadata or the archival index. The byte count is unambiguous and platform-independent. Future users consulting the archive will not need to guess which unit system was used when the size was recorded.
The PDF portfolio container itself adds overhead to the total file size. The container structure, navigation interface, and metadata contribute a fixed amount regardless of the number of files in the portfolio. For portfolios with few small files, the container overhead can be a significant percentage of the total size.
Compression applied by the file system, such as NTFS compression on Windows, reduces the disk space used but does not change the reported file size. The size shown in file properties is the uncompressed size of the portfolio.
When a PDF portfolio is stored on a network drive or cloud-synced folder, the file size reported by the local file system may differ from the size reported by the remote storage. The local system shows the cached copy size.
Portfolio files that contain embedded files within embedded files create nested compression scenarios. The reported size reflects the outer container, not the sum of the decompressed inner content sizes.
Some PDF portfolio viewers extract and cache the embedded files when the portfolio is opened, creating additional local storage consumption beyond the portfolio file itself. The cache size does not affect the reported portfolio size.
When transferring portfolios between systems, verifying the file integrity with a checksum is more reliable than comparing reported file sizes. Matching checksums confirm the files are identical regardless of how each system reports the size.
Organizations that distribute PDF portfolios to external recipients can include a note about expected file size and the platform used to determine it. The note prevents support inquiries about mismatched file sizes.
ISO standard for PDF portfolios specifies how embedded files are stored and referenced but does not standardize how file managers should calculate and display the portfolio size. The lack of a display standard leads to platform variation.
For archival storage planning, use the byte count from the original system as the authoritative size. Archive storage capacity calculations based on file counts and average sizes should use byte counts, not platform-specific display values.
Understanding that file size display varies by platform eliminates unnecessary troubleshooting when a colleague on a different operating system reports a different size for the same portfolio file.
| Platform | Unit System | 1 KB = | Reported Size for 1,048,576 bytes |
|---|---|---|---|
| Windows | Decimal (KB/MB) | 1000 bytes | 1,024 KB (1.02 MB) |
| macOS | Binary (KiB/MiB) | 1024 bytes | 1,024 KiB (1.00 MiB) |
| Linux | Binary (KiB/MiB) | 1024 bytes | 1,024 KiB (1.00 MiB) |
| Cloud (web UI) | Varies by provider | Varies | Varies |
Confusion between binary and decimal units has a long history in computing. Hard drive manufacturers adopted decimal units for marketing because a 500 GB drive sounds larger than a 465 GiB drive. Operating system developers generally use binary units because computers work in powers of two. The PDF sits in the middle of this decades-old unit conflict.
Emailing a PDF portfolio, the email system may report the attachment size using yet another unit convention. Microsoft Outlook uses decimal units. Apple Mail uses binary units. The same attachment appears as a different size in the two email clients.
Cloud storage services like Dropbox, Google Drive, and OneDrive each have their own file size display conventions. Dropbox uses binary units. Google Drive uses decimal units. A PDF portfolio stored in both services appears to have a different size in each web interface.
For legal and regulatory filings where the file size is specified in the filing requirements, the requirement should state the unit system. A requirement that says files must be under 10 MB is ambiguous. A requirement that says files must be under 10,000,000 bytes is unambiguous.
The solution to the file size reporting confusion is simple: always communicate file sizes in bytes for precision, and specify the unit system when using larger units for readability. A file size of 12,582,912 bytes is approximately 12 MB in decimal or 12 MiB in binary.
The file size reporting variation between operating systems is a common source of confusion that is easily resolved by communicating sizes in bytes.