Running tests when dealing with large files

Questions
1

When running a test with a large binary file, n8n prompts you to execute the FULL workflow, and any large files cannot be pinned.

image
image324Ă—125 8.34 KB

Once I get a binary file via API call, I cannot pin the data, due to file size. Therefore, I do not know how to test the workflow without waiting 3 minutes for the file to be continually reproduced, and a nice fat bill at the end of the month for API use. There has to be a way to test such a workflow. Anyone have any ideas?

TYIA

1 Like
2

Hi @expozeur,

I’d recommend testing with a very small sample size. You can also replicate the data structure, and use a code block to create sample data instead of connecting it to real data. Test on the small data, and move to real data once you are comfortable with with the workflow.

Best,

Robert

3

Hi!

You’re totally right — this is a common pain point when working with large binary files in n8n. Since pinning is limited to 12MB, testing workflows that involve binaries (like PDFs, videos, or images from APIs) becomes tricky. Here are some ideas you can try:

Option 1: Simulate Binary with a Smaller File

Use a Set node or local file to inject a smaller sample version of the binary file (e.g., trim a PDF, use a small JPG). You can mimic the file structure like this:

{
  "binary": {
    "data": {
      "mimeType": "application/pdf",
      "fileName": "test.pdf",
      "data": "BASE64_STRING_HERE"
    }
  }
}

Just make sure the base64 content is below 12MB.

Option 2: Use Test Mode + Disable Trigger

You can disable the API trigger node (or mock it with static data), run the workflow from any middle node, and simulate the input manually. It won’t be exactly the same binary, but lets you test the logic downstream.

Option 3: Save the File Once, Then Read from Disk

  1. Let the binary download once from the API.
  2. Use a Write Binary File node to store it locally (e.g., /tmp/sample.pdf)
  3. Temporarily replace the HTTP Request node with a Read Binary File node during testing.

This avoids repeated API calls while you test the rest of the workflow.

Bonus: Feature Request

You could consider voting for or proposing a feature like “Simulated Pin for Binary Metadata” — just pin the file reference, not the whole payload.

2 Likes
4

@Erick_Torres
Good description of the options. Helps me think through this as well.

1 Like
5

Yes try to reduce down a sample dataset which is best for testing in the GUI

6

This is good! For options 1 and 2 though, does this insinuate that this is not possible on a cloud version? I’m self-hosting via RepoCloud, not a local machine — so how would it be possible to even “test” with a file? Would it have to be hosted to Google Drive, for example, and then fetech/downloaded in the actual execution?

7

You can change the URL here:

You can use FTP, or try options like Google Drive. But if you use Google Drive, remember the credentials and permission type.

I used this for RAG, but I did it from FTP.