Make one real URL before you keep reading

Upload a file up to 10 MB. The public URL works immediately, with no password or credit card. Executable files require email verification.

n8n Binary Data to Public URL with the FilePost Node

· · 7 min read

n8n already knows which fields are JSON and which are binary. The FilePost node can take the binary property directly, upload it, and expose the returned URL to the following node.

The easiest pattern is simple: select the binary property in the FilePost node, run it, and use the returned url in the next node. No multipart request configuration is required.

Quick setup

  • Best path: use the verified FilePost community node in n8n.
  • Manual path: use the built-in HTTP Request node when you want full request control.
  • Input: an n8n binary property, often named data.
  • Output: JSON containing url, file_id, file name, size, and content type.

The automation contract

Keep the workflow boundary simple:

  1. Read the binary property produced by the previous node.
  2. Upload it to FilePost with the file multipart field.
  3. Pass $json.url to the database, webhook, email, CMS, or next automation step.

The upload step does not need to change when the file is generated, downloaded, or attached to a form submission.

What n8n Binary Data Actually Means

In n8n, each item can have JSON data and binary data. The JSON side is regular fields like names, IDs, and URLs. The binary side is where files live.

A previous node might output something like this:

{
  "json": {
    "filename": "invoice.pdf",
    "customer": "Acme"
  },
  "binary": {
    "data": {
      "fileName": "invoice.pdf",
      "mimeType": "application/pdf"
    }
  }
}

The important part is the binary property name. In this example it is data. In your workflow it might be attachment_0, file, or another name chosen by the previous node.

Method 1: FilePost Node

If the FilePost community node is available in your n8n instance, use it for the guided path. Otherwise, the built-in HTTP Request node below sends the same multipart request.

  1. Open the nodes panel and search for FilePost.
  2. Install the FilePost community node if it is not already available.
  3. Create FilePost credentials with your API key.
  4. Add the FilePost node after the node that produced the binary file.
  5. Choose Upload File.
  6. Set the binary property to the property from your previous node, for example data.

The node returns a JSON response you can use immediately in later steps:

{
  "file_id": "a1b2c3d4e5f6",
  "url": "https://cdn.filepost.dev/file/filepost/uploads/a1/a1b2c3.pdf",
  "name": "invoice.pdf",
  "size": 248102,
  "content_type": "application/pdf"
}

Use {{ $json.url }} in the next node to insert the public URL into Slack, Airtable, Google Sheets, HubSpot, Notion, or any other service.

Method 2: HTTP Request Node

If you do not want a community node, use n8n's built-in HTTP Request node. For current field-by-field screenshots and troubleshooting, continue to the dedicated n8n HTTP Request binary upload guide.

Setting Value
Method POST
URL https://upload.filepost.dev/v1/upload
Header X-API-Key: fh_...
Body type Form-Data
File parameter name n8n Binary File, name file
Binary property data, or whatever your previous node outputs

After the request runs, the response body becomes the JSON input for the next node. The public URL is available at:

{{ $json.url }}

Example Workflow: Form Upload to Public URL

This is the common workflow shape:

  1. Webhook or form trigger. Receive a submitted file.
  2. File download step if needed. If the form tool sends a temporary URL, download it as binary data first.
  3. FilePost upload. Upload the binary property to FilePost.
  4. Store or send the URL. Write {{ $json.url }} to Airtable, Google Sheets, Slack, Notion, or a database.

If the previous service gives you a temporary file URL, do not store that URL as the final value. Download it, upload the file, and store the FilePost URL instead.

Example Workflow: Airtable Attachment to URL with No Automatic Expiry

Airtable attachment download URLs expire after a short time. In n8n, the workflow looks like this:

  1. Airtable trigger finds a record with an attachment.
  2. HTTP Request downloads the Airtable attachment URL as binary data.
  3. FilePost uploads that binary file and returns a URL with no automatic expiry by default.
  4. Airtable update writes the CDN URL to a separate Public URL field.

That gives Airtable users a stable public URL without using Airtable itself as a CDN.

Generated files and batch runs

If an earlier node creates an audio file, image, document, export, or other asset, the handoff is the same: keep the result as n8n binary data, upload it, and store the returned URL. For repeated runs, keep the upload response with the item that produced it so downstream nodes can associate each URL with its source record.

Troubleshooting

No binary data found

Open the output of the previous node and look for the binary section. Use the exact property name shown there. If there is no binary section, configure the previous HTTP Request node to return a file rather than JSON or text.

Uploaded file is named data

The binary property name and the file name are separate. If n8n only has a generic binary property, set the filename in the previous node or make sure the download step preserves response headers.

413 or file too large

Check both sides. FilePost has plan limits, 50 MB on Free, 100 MB on Lite, 200 MB on Starter, and 500 MB on Pro. n8n itself can also run into memory limits before the upload reaches FilePost.

The next node cannot see the URL

Make sure the next node reads the output of the FilePost or HTTP Request node, not the original trigger node. The URL lives in the upload response at $json.url.

Run your first automated upload

To test the workflow, upload one binary item and confirm that the next node can read $json.url. Check the current plan limits before running larger batches.

Test a binary upload

References