I’m trying to read a txt file on a windows server but it has trouble reading from a folder if it contains brackets or other special characters. So to fix this I need escape the brackets but for some odd reason n8n is replacing backslash with forward slash. Does anyone know how to fix this?
@Ruriko
A simple workaround is to move or copy the file to a path without brackets or special characters, such as C:\n8n-files\input.txt, and have n8n read from that sanitized path instead.
The reason that this is happening is because n8n processes the path as a string and normalizes slashes. This is a known quirk with running n8n on Windows. Moving the file to a different folder would help, though here is what you could try instead:
-Use double backslashes to escape something like, “C:\\folder (with brackets)\\file.txt”. The first backslash does the escaping which means the second survives string processing.
-Put the path in an expression using ‘$json’ or a Set node to construct it, rather than typing directly into the field this can sometimes bypass the normalization.
-If you are self-hosting, using a UNC path(‘\\\\server\\share\\folder’) can sometimes sidestep the issue.
What node are you reading the file with? This will help narrow it down.
In my workflow I have already tried putting the path into an expression and it didn’t work. I’m using the Read/Write node to read the file. The thing is that in version 1.x it worked but when moving to 2.x it nolonger works cause it’s replacing backslash with forwardslash
@Ruriko your Edit Fields1 expression calls .replaceAll(‘\’,‘/’) first — that’s you converting backslashes, not n8n. Drop the replace and just escape the brackets, or use forward slashes throughout since readWriteFile accepts them on Windows.
Hey @Ruriko, great that you shared the workflow screenshot - that makes it much easier to understand!
This is a known quirk when building paths in n8n expressions on Windows. The expression engine treats backslash as an escape character, so \[ gets normalized to /[ or stripped.
The cleanest fix is to build the path in a Code node (not an expression) where you have full JavaScript control:
const folderName = $('Edit Fields').item.json.folderName; // your input
const safePath = 'C:\\Users\\Admin\\Desktop\\' + folderName;
// or use String.raw if the folder name comes from input:
const filePath = String.raw`C:\Users\Admin\Desktop\` + folderName;
return [{ json: { filePath } }];
Then use {{ $json.filePath }} in your Read/Write Files node.
Alternatively, if you want to keep the expression approach, you can replace forward slashes back to backslashes inside the expression:
{{ $json.path.replace(/\//g, '\\') }}
Did @achamm’s workflow example work for you? If you can share what your current path value looks like after the Edit Fields node, we can pinpoint exactly where the slash substitution is happening.
Hi @Ruriko
Thanks for sharing this very interesting Windows path issue.
One thing that may help is to build the final path in a Code node using path.join() instead of manually escaping the string in expressions. Since the n8n Code node runs on the Node.js runtime: this can be a cleaner way to normalize separators and keep the path construction deterministic.
Add a backslash before each square bracket directly in the File(s) Selector field:
\[A+B\]/file.txt
C:/Users/Administrator/Desktop/Data/Test \[A+B\]/file.txt
or Use .replaceAll() in an expression
If the path comes from a dynamic expression (e.g., from a previous node), use .replaceAll() to escape the special characters programmatically
