Cookie Converter
Convert a cookie export between Netscape cookies.txt, the Puppeteer and EditThisCookie JSON shape, and a Cookie header string. The format is detected for you, and nothing leaves this page.
- Runs entirely in your browser
- Nothing uploaded, nothing stored
- No signup
Paste a cookies.txt file, a JSON array from an extension or an automation script, or a raw Cookie header. The format is detected from the content.
Converted
Every attribute the source carried survives this conversion.
Paste an export on the left and the converted version appears here.
This runs in your browser
- Everything happens in this tab. What you paste is never sent to Sendwin or to anyone else.
- What you paste is never written to local storage, session storage, a cookie or the address bar.
- Nothing from this tool is printed to the browser console.
- Close or reload the tab and your input is gone.
Now give every account its own device.
A clean browser is still one browser. Sendwin runs each profile in isolation with its own fingerprint, cookies and proxy, so the accounts you work on never look like they came from the same machine.
- Isolated profiles, each with its own fingerprint and cookies
- A proxy per profile, with the timezone bound to the proxy country
- Windows, macOS and Linux — plus cloud sessions when you need them
The free plan includes 10 minutes of cloud browsing a day.
Three formats for the same session
Every tool that touches cookies stores them differently. curl, wget and yt-dlp read the Netscape cookies.txt format, a tab-separated file that has barely changed since the 1990s. Browser extensions and automation libraries — EditThisCookie, Puppeteer, Playwright — work with JSON arrays of objects with named fields. An HTTP client or a quick test with curl often just wants a single Cookie header line of name=value pairs. Retyping a session between those by hand is slow and easy to get wrong: one wrong column in a cookies.txt file and the whole line is skipped without an error anywhere.
So paste an export in any of the three, and this page works out which one it is and rewrites it into the others. All of it happens in this browser. Nothing is uploaded, nothing is written to localStorage, sessionStorage, IndexedDB or the address bar, and nothing is printed to the console — close the tab and both the input and the output are gone. That matters more here than on most tools, because a cookie export is not a preference file. It is the credential that keeps you logged in.
The three formats, and what each one can carry
Netscape cookies.txt is seven tab-separated columns: domain, an include-subdomains flag, path, a secure flag, expiry as a Unix timestamp, name, and value. The JSON shape keeps considerably more — httpOnly, sameSite, hostOnly, session, an expirationDate with decimals, sometimes a partition key. The header form keeps the least: name=value pairs separated by semicolons, with no domain, path, expiry or flags at all, which is why it is only valid for the one host you send it to. Converting toward the header form is lossy by definition, and no converter can invent those fields back.
httpOnly, secure, sameSite and session cookies
These four attributes decide how a cookie behaves, and they are the usual reason a converted file does not work. httpOnly means JavaScript cannot read the cookie, so an export taken from document.cookie in the console is missing exactly the session cookies that matter; an extension or DevTools export includes them. Secure restricts the cookie to HTTPS. SameSite governs whether it rides along on cross-site requests — Lax by default, and None requires Secure. A session cookie has no expiry at all and is meant to die with the browser, which cookies.txt records as an expiry of 0.
Treat an exported cookie file like a password
A valid session cookie is a bearer credential: whoever holds it is logged in as you, without your password and usually without a second-factor prompt, until the site expires the session or you log out everywhere. That makes an export far more dangerous than the file extension suggests. Do not paste one into a converter that posts it to a server, do not send it over chat, and do not leave it in a repository or a downloads folder. It is also why this page converts locally — a tool that handles credentials should not be a place credentials travel to.
How the conversion runs
- 1
Paste the export
Drop in a cookies.txt file, a JSON array from an extension or an automation script, or a raw Cookie header line. The shape is detected from the content, so there is nothing to select first.
- 2
Pick the output format
The conversion runs as you type. Fields the target format cannot hold are dropped because the format has no column for them — a header line carries name and value and nothing else — rather than being guessed at.
- 3
Copy the result out
Take it into your client, your script or an isolated browser profile. Nothing is retained on this page: reloading clears both boxes, and there is nothing on our side to delete.
Other free checks
The other tools that work on something you paste in, and the one that measures the browser you paste it into.
Cookie format FAQ
What each format can carry, what httpOnly and SameSite actually do, and why a faithfully converted export can still fail to log you in.
It is the Netscape cookie file format, the plain-text layout curl, wget and yt-dlp expect. Each line is one cookie in seven tab-separated columns — domain, include-subdomains flag, path, secure flag, expiry as a Unix timestamp, name and value — with comment lines starting with a hash. Tabs are required; a file that looks right but uses spaces is parsed as nothing at all, which is the single most common reason one silently fails to load.
They were designed for different jobs at different times. cookies.txt came out of the original Netscape browser and stuck around because command-line tools standardised on it. The JSON shape grew out of browser extensions and automation libraries, which needed the attributes the old format has no column for, such as httpOnly and sameSite. The Cookie header is not a storage format at all — it is what the browser actually transmits on a request, so it carries only what the server needs to read.
httpOnly means the cookie is invisible to JavaScript and is sent only by the browser itself, which is how sites protect session cookies from scripts. Secure means it is only ever sent over HTTPS. SameSite controls cross-site behaviour: Strict sends the cookie only on same-site navigation, Lax adds top-level navigations, and None allows cross-site use but is rejected unless the cookie is also Secure. None of the three appear in a cookies.txt file, which is why a round trip through that format loses them.
One with no expiry set. The browser is supposed to discard it when it closes, so it never lands on disk in a normal profile. In a JSON export it usually shows as session: true with no expirationDate; in cookies.txt the expiry column is 0. Converting one does not make it permanent — the receiving tool decides how long to keep it, and the server can still invalidate it whenever it wants.
No. The detection and the conversion run in JavaScript on this page, there is no request to us with your data in it, and nothing is written to localStorage, sessionStorage, IndexedDB or the URL. Nothing is logged to the console either. If you want to confirm it rather than take our word for it, open your network tab while you convert, or disconnect from the internet — the page keeps working.
Almost always something the conversion cannot fix. The export may have come from document.cookie, which cannot see httpOnly cookies and therefore missed the session one. The cookie may have expired, or the site may have invalidated the session when it saw a new address or a different browser. The domain may be wrong — a host-only cookie for app.example.com is not sent to example.com. Converting the format faithfully does not make a dead session live again.
Yes — Sendwin supports cookie import, and each profile keeps its own cookie jar alongside its own fingerprint and its own proxy, so a session you import stays inside that profile instead of mingling with everything else you are logged into. That is generally a better home for a working session than a text file on your desktop: profiles are the thing designed to hold credentials, and a loose export is the thing designed to be copied.
Still have questions? Talk to us →
What this page does not do
This page converts, it does not validate. It cannot tell you whether a cookie is still accepted by the site it came from, whether the session behind it is alive, or whether the export was complete when you took it. And converting a credential does not make it less of a credential: the output is exactly as sensitive as the input, so handle the result the way you would handle the password it stands in for.
A session belongs in a profile, not a text file.
Sendwin imports cookies straight into an isolated profile that keeps its own fingerprint and its own proxy, so the session you just converted stays where it was meant to live. Free for 30 days on Windows, macOS and Linux.
30-day free trial · $0 today · cancel anytime — your profiles stay on your machine