cURL to PowerShell Converter — Invoke-RestMethod, Splatting-Ready
Paste a cURL command and get production-shaped PowerShell: an @{} parameter hashtable splatted into Invoke-RestMethod, JSON bodies in single-quoted here-strings (no interpolation), headers as a hashtable, and -u credentials pre-encoded as a Basic Authorization header. The whole conversion runs offline in your browser.
Zero upload, ever
Parsing and code generation run in your browser — URLs, headers, and tokens never touch a server.
Live 100 ms conversion
Output updates as you type or paste, with one-keystroke copy via Cmd/Ctrl + Enter.
Splatting-native output
A parameter hashtable you can extend with TimeoutSec, MaximumRedirection, or -SslProtocol in one line.
Paste a cURL command to convert
cURL command
Paste a cURL command — idiomatic code appears here instantly, converted entirely in your browser.
Technical documentation
How cURL maps to Invoke-RestMethod
PowerShell's Invoke-RestMethod is the REST-native sibling of Invoke-WebRequest: it sends the request and parses the response for you — JSON arrives as objects, not strings — which is why the generated snippet ends with $response | ConvertTo-Json -Depth 10 rather than response-body plumbing. The converter maps your command onto a $params = @{...} hashtable — Uri, Method, Headers, Body, ContentType — and splats it with Invoke-RestMethod @params, the community style that keeps the call readable and trivially extensible with TimeoutSec, RetryCount logic, or session variables.
Method names follow PowerShell's convention (Get, Post, Put, Patch, Delete, Head, Options; custom verbs pass through as written), and the Content-Type header routes into the -ContentType parameter the cmdlet actually consumes, matching how Invoke-RestMethod separates content headers from request headers. A GET with no body emits just Uri and Method — no dead parameters — and query strings survive verbatim in the URL exactly as curl would send them.
Here-strings, quoting, and the '@' edge case
The generated body uses a single-quoted here-string (@' ... '@) — PowerShell's verbatim multi-line literal with no interpolation — so JSON payloads appear exactly as they travel, with $characters and backslashes immune to PowerShell's parser. Header values and the URL use single-quoted strings with apostrophes doubled per PowerShell rules, the same escaping discipline the other generators apply for their languages. The one pathological input — a body containing a line that starts with '@ — falls back to a single-quoted one-line literal so the here-string can never terminate early.
PowerShell's parsing quirk worth knowing when you adapt the snippet: the closing '@ of a here-string must be at the start of a line with nothing before it — which the generated formatting guarantees — and Invoke-RestMethod sends the here-string's bytes untouched, including the leading and trailing newlines the literal adds around your payload. Servers ignore trailing newlines in practice; the pedantically exact can trim inside the hashtable assignment.
Auth, TLS, and Windows PowerShell 5.1 versus PowerShell 7
Basic auth from -u — or credentials embedded in the URL — is base64-encoded at conversion time and emitted as an Authorization header entry in the Headers hashtable, byte-identical to what curl sends with no runtime encoding code in the snippet. Explicit Authorization headers (bearer tokens) pass through untouched, and when both exist the precomputed Basic header is suppressed to avoid sending two credentials. PowerShell's -Authentication Basic -Credential alternative needs a PSCredential object and prompts interactively in some hosts — the header form is the copy-paste-safe one.
The output targets PowerShell 7+ (pwsh) on any OS and works unchanged on Windows PowerShell 5.1 for plain http/https endpoints. The 5.1 caveats live in TLS: older hosts default to TLS 1.0/1.1 and need [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 before the call, and some corporate proxies require -Proxy credentials. PowerShell 7 defaults sensibly and adds -SslProtocol and -SkipCertificateCheck for the -k/--insecure cases curl users ask about — one added hashtable line each.
From snippet to script: errors, pagination, and reuse
Wrap the call in try/catch for production use: Invoke-RestMethod throws on non-2xx (like curl --fail, unlike plain curl), and the catch receives $_.Exception.Response with status code and headers for retry decisions. The splat shape makes the natural next steps one-liners: add TimeoutSec = 30 for curl's --max-time, MaximumRedirection for --max-redirs, and -MaximumRetryCount with -RetryIntervalSec for the retry behavior curl users usually hand-roll.
For repeated calls, lift $params into a function or a configuration file and splat from there; the hashtable composes with PowerShell's parameter binding exactly the way it reads. Response handling is already idiomatic — Invoke-RestMethod returns parsed objects, so $response.items | Where-Object {...} works directly — and ConvertTo-Json -Depth 10 in the snippet exists purely so a raw run prints something readable in the console.
Frequently asked questions
Does this converter produce Invoke-WebRequest or Invoke-RestMethod?
Invoke-RestMethod — the REST-optimized cmdlet that parses JSON, XML, and form responses into objects automatically. It is the right default for API calls and the closest single-command equivalent to curl's request-plus-body workflow. Invoke-WebRequest remains the tool for raw HTML scraping and full response-object access (status codes, headers, raw content); converting the generated hashtable between the two is a cmdlet-name swap because the parameters match.
Is the output for Windows PowerShell 5.1 or PowerShell 7?
Both, for standard http/https requests — the generated splat and here-string syntax run unchanged in either. Two 5.1-specific gaps to know: older hosts may need [Net.ServicePointManager]::SecurityProtocol set to TLS 1.2 before the call, and -SslProtocol / -SkipCertificateCheck (the curl -k equivalents) exist only in PowerShell 7. On any OS with pwsh installed, the snippet works as generated.
How is basic auth (-u) converted for PowerShell?
The user:password pair is base64-encoded during conversion and emitted as an Authorization: Basic entry inside the Headers hashtable — byte-identical to what curl puts on the wire, with zero runtime encoding code to maintain. If your command already carries an Authorization header (a bearer token, for example), it passes through untouched and the generated Basic header is skipped so two credentials never collide.
Why is my JSON body in an @'...'@ here-string?
Single-quoted here-strings are PowerShell's verbatim literal: nothing interpolates, so $variables, backslashes, and quotes in your payload survive untouched — the same guarantee JSON needs. The alternative (a double-quoted string) would interpolate $tokens and require escaping every quote; the here-string keeps the payload copy-paste-safe and diff-friendly. The closing '@ always sits at the start of its line, exactly as PowerShell requires.
How do I add a timeout or retry to the generated command?
Add hashtable entries — that is the point of the splat shape. TimeoutSec = 30 reproduces curl's --max-time; -MaximumRetryCount 3 -RetryIntervalSec 2 (switch-style parameters appended after @params) adds bounded retries; MaximumRedirection covers --max-redirs. Because $params is just a hashtable, versioning it in a config file or passing different values per environment is plain PowerShell, not a converter feature.
Is my cURL command uploaded anywhere during conversion?
No. The converter is a static page that transpiles entirely in your browser — commands with production tokens, cookies, or basic-auth credentials are never transmitted, stored, or logged.