n8n-io/n8n · warning · BadRequestError

Invalid binary data mode

Error message

Invalid binary data mode

What it means

BadRequestError (HTTP 400) 'Invalid binary data mode' thrown at binary-data.controller.ts:64 when the prefix before the `:` is not one of the recognized stored modes. Valid modes (from `STORED_MODES`) are: `filesystem`, `filesystem-v2`, `s3`, `azure`, `database` — `default` is explicitly excluded by `isValidNonDefaultMode`.

Source

Thrown at packages/cli/src/controllers/binary-data.controller.ts:64

			else throw error;
		}
	}

	private validateBinaryDataId(binaryDataId: string) {
		if (!binaryDataId) {
			throw new BadRequestError('Missing binary data ID');
		}

		const separatorIndex = binaryDataId.indexOf(':');

		if (separatorIndex === -1) {
			throw new BadRequestError('Malformed binary data ID');
		}

		const mode = binaryDataId.substring(0, separatorIndex);

		if (!isValidNonDefaultMode(mode)) {
			throw new BadRequestError('Invalid binary data mode');
		}

		const path = binaryDataId.substring(separatorIndex + 1);

		if (path === '' || path === '/' || path === '//') {
			throw new BadRequestError('Malformed binary data ID');
		}
	}

	private async setContentHeaders(
		binaryDataId: string,
		action: 'view' | 'download',
		res: Response,
		fileName?: string,
		mimeType?: string,
	) {
		try {
			const metadata = await this.binaryDataService.getMetadata(binaryDataId);

View on GitHub (pinned to 5ac6606e81)

Solutions

1. Use a mode that matches the deployment's `N8N_DEFAULT_BINARY_DATA_MODE` (or one of: filesystem, filesystem-v2, s3, azure, database).
2. After migrating binary storage, re-run executions so IDs carry the new mode prefix.
3. Never emit `default:` IDs — `default` is a sentinel, not a stored mode.

Example fix

// before
GET /binary-data?id=default:exec-123/data
// 400 Invalid binary data mode

// after
GET /binary-data?id=filesystem-v2:exec-123/data

const MODES = ['filesystem','filesystem-v2','s3','azure','database'] as const;
function validMode(id: string) {
  const m = id.slice(0, id.indexOf(':'));
  return (MODES as readonly string[]).includes(m);
}
// guard the fetch: if (!validMode(id)) rebuild id with the deployment's mode

const STORED_MODES = ['filesystem','filesystem-v2','s3','azure','database'] as const;
type StoredMode = typeof STORED_MODES[number];
const isStoredMode = (m: string): m is StoredMode => (STORED_MODES as readonly string[]).includes(m);

try { await get(req); } catch (e) { if (e instanceof BadRequestError && /Invalid binary data mode/.test(e.message)) {/* map to configured mode */} }

When it happens

Trigger: Passing `id=default:...` or any unknown prefix (`id=gcs:...`, `id=foo:...`). Common when an instance was running in `default` mode and a caller stored the legacy ID, or when the storage backend was reconfigured.

Common situations: Upgrading/migrating binary storage mode; mixing instances with different `N8N_DEFAULT_BINARY_DATA_MODE`; clients assuming a mode the deployment doesn't use.

Related errors

• error.message
• Missing binary data ID
• Malformed binary data ID
• Content not viewable
• output.error.errors[0]

AI-assisted analysis of n8n-io/n8n@5ac6606e81 (2026-08-12). Data as JSON: /api/errors/2655bc12254be711. Report an issue: GitHub.