Multipart file upload corrupts binary .xlsx on Windows in Postman 12.0.8, while curl sends the file correctly

[OSmall]

Is there an existing issue for this?

• I have searched the tracker for existing similar issues and I know that duplicates will be closed

Describe the Issue

On Windows, Postman corrupts a binary .xlsx file when sending it as a multipart/form-data file field.
The same file, sent to the same endpoint with curl, is uploaded correctly and succeeds. The Postman request fails because the uploaded file cannot be parsed as a valid Excel file.
This reproduces even with a brand-new request in Postman.

Steps To Reproduce

1. Create a new POST request in Postman.
2. Set the body type to form-data.
3. Add a file field and select a local .xlsx file.
4. Send the request to any endpoint that parses the uploaded Excel file.
5. Observe that the server fails to parse the file.
6. Send the equivalent request with curl using the same file.
7. Observe that the curl request succeeds.

Screenshots or Videos

Operating System

Windows

Postman Version

12.0.8

Postman Platform

Postman App

User Account Type

Signed In User

Additional Context?

Expected behavior

Postman should send the exact raw bytes of the selected file in the multipart upload.

Actual behavior

Postman sends different file bytes than the original file on disk, and the uploaded .xlsx is corrupted.

Evidence

I compared the raw multipart requests from Postman and curl.

Original file on disk

• Size: 19696 bytes
• SHA-256: dd90894dba0627ccd0908fcbc4d321c6fa4e0090bd884df714012d96f6a14f0c

File bytes sent by curl

• Size: 19696 bytes
• SHA-256: dd90894dba0627ccd0908fcbc4d321c6fa4e0090bd884df714012d96f6a14f0c

This exactly matches the file on disk.

File bytes sent by Postman

• Size: 31287 bytes
• SHA-256: 7979250e75901bdc2ff1567e0d4aa2daff8ad5ff7fa942e41e0e7b7fd0ed0c10

This does not match the file on disk.

Additional technical finding

The corrupted Postman payload exactly matches this transformation of the original file bytes:

original_bytes.decode("utf-8", "replace").encode("utf-8")

That suggests the file is being treated as text instead of raw binary during request construction. The resulting payload contains many UTF-8 replacement bytes (EF BF BD) and is no longer a valid XLSX/ZIP.

Why this looks like a Postman bug

• Same source file
• Same endpoint
• Same multipart structure
• curl sends the correct bytes
• Postman sends different bytes
• Recreating the request from scratch does not fix it

[OSmall]

Here are the raw captures of the different http interactions

postman.txt

curl.txt

[deve-sh]

Hi @OSmall Thank you very much for reporting this issue and taking your time to compile the detailed steps to reproduce it.

Let us check this and get back to you at the earliest with a resolution.

[deve-sh]

@OSmall Thanks a lot again for your detailed bug report. 🙌🏼

We've identified the issue, and will raise a fix for this ASAP + Notify you when it's out.

[qvattr0]

I've actually been having this issue with other types of data as well. In my case, the corrupted data are JPEG files that are not decodable if sent through Postman request. My platform is macOS but my Windows client exhibits the same behavior.