How to Use the Axios Validator: Step-by-Step Tutorial

The Axios Validator runs entirely in your browser — no config data is sent to any server, no account is required, and any API keys or tokens inside your configs stay on your machine. This tutorial walks through every step of using the tool: choosing a validation mode, loading a config, reading the results, and working through practical examples that cover the most common Axios config issues encountered by designers and developers.

Connect on LinkedIn →

Step 1 — Open the Tool

Navigate to /developer-tools/axios-validator/. The tool loads entirely in the browser. After the initial page load, no further network requests are made when you validate a config. You can confirm this by opening DevTools (F12 → Network) and observing that validation produces zero outbound requests.

The tool is reachable from the Developer Tools hub, directly via the URL above, or through the site command palette — press Ctrl+K (Windows/Linux) or ⌘K (macOS) and type "Axios Validator".

Step 2 — Choose Validation Mode

At the top of the tool box, two mode tabs let you choose what you are validating:

• Request Config — validate the object you pass to axios(config) or any Axios method shorthand. This checks the url, method, headers, auth, timeout, responseType, and other config fields.
• Response Object — validate the object that Axios returns after a completed request. This checks the shape of status, statusText, headers, data, and config.

Select the mode that matches what you are pasting. The placeholder JSON in the text area updates to show an example of the expected shape for each mode, so you can see the format before entering your own data.

Step 3 — Load Your Config

There are three ways to get a config into the validator:

Option A — Paste JSON directly. Click inside the text area and paste your Axios config or response object as a JSON string. Both compact ({"url":"..."}) and formatted multi-line JSON are accepted.

Option B — Drop a JSON file. Drag a .json or .js file from your file manager onto the drop zone at the top of the tool box. The file is read as plain text and its content is placed into the text area. This is useful when you have a config saved in a project file that you want to validate without copying and pasting.

Option C — Use a sample. Click one of the sample chips — ✓ Valid Request, ⚠ Bad Request, ✓ Valid Response, or ⚠ Bad Response — to load a pre-written example instantly. The "Bad" examples are particularly useful: they show configs with deliberate errors so you can see exactly what the error output looks like before working with your own data.

Step 4 — Run Validation

Once a config is in the text area, click the Validate button. Alternatively, press Ctrl+Enter (Windows/Linux) or ⌘+Enter (macOS) to validate without reaching for the mouse.

The Clear button resets everything: it empties the text area, removes any loaded file, and clears all result panels. Use it to start fresh with a different config.

Step 5 — Read the Status Bar

Immediately below the button row, a status bar appears with one of three states:

• Green — Valid Axios config. The config passed all checks with no errors or warnings. The parsed breakdown below will show the extracted fields.
• Yellow — Valid with warnings. The config is structurally sound but contains one or more fields or values that deserve attention. The warning count is shown. Read the Warnings panel for details.
• Red — Validation failed. The config contains one or more errors that would cause Axios to throw, silently ignore a field, or behave differently than intended. The error count is shown. Read the Errors panel for details.

Step 6 — Read the Parsed Breakdown

For any config that at least partially parses, the result area shows several panels:

Summary stat cards

Four cards summarize the config at a glance: the detected Mode (request or response), the effective Method, the URL (truncated for long values), and the Field Count — the number of recognized top-level fields in the config. These give you a quick confirmation that the validator understood the config the way you intended.

Fields breakdown table

A detailed row-by-row breakdown of every field the validator detected:

• Field — the config field name (e.g., url, method, headers)
• Type — the JavaScript type of the value (string, object, number, boolean)
• Value — the actual value, shown verbatim for short values. Auth credentials are redacted.
• Status — whether the field is known (a recognized Axios field) or unknown (not a standard Axios config key, which may indicate a typo or a custom field)

This table is the fastest way to confirm that every field in your config will be seen and used by Axios the way you expect.

Step 7 — Understand Errors and Warnings

Errors panel (red)

Each error describes a structural problem with the config. Common errors:

• "Missing required field: url" — no url field is present in the config. Axios cannot make a request without one.
• "Field 'url' must be a string" — the url field is present but is not a string (for example, it is null or a number).
• "Invalid HTTP method" — the method field contains a string that is not a recognized Axios HTTP method (get, post, put, patch, delete, head, options).
• "Field 'headers' must be an object" — the headers field is present but is an array, string, or other non-object type. Axios will not apply any headers from a non-object value.
• "Field 'auth' must be an object" — the auth field is present but is not an object with username and password properties.
• "Input is not valid JSON" — the text in the area could not be parsed as JSON. Check for trailing commas, unquoted keys, or single quotes (JSON requires double quotes).

Warnings panel (yellow)

Each warning describes a condition that is not a parse failure but that may produce unexpected behavior:

• "timeout is 0 (no timeout)" — a timeout of zero means the request will wait indefinitely. Consider setting an explicit timeout for any request used in a live prototype or integration.
• "Unknown responseType" — the responseType value is not one of the recognized Axios response types (json, text, blob, arraybuffer, document, stream).
• "auth field and Authorization header both present" — both an auth object and an explicit Authorization header are present. Axios will use the auth field and overwrite the header; the explicit header will be lost.
• "Non-string header value" — a header value is a number or boolean. Axios may coerce it to a string, but the result may not be what was intended.
• "Unknown field detected" — a field name is not a standard Axios config key. This is often a typo, such as baseUrl instead of baseURL. The field will be silently ignored by Axios.

Step 8 — Fix and Re-Validate

After reading the errors and warnings, edit the JSON in the text area directly — you do not need to clear and re-paste. Make your changes, then click Validate again (or press Ctrl+Enter). The results panels refresh immediately.

Efficient fix workflow:

1. Address errors first — they are the structural problems that will cause Axios to throw or silently fail.
2. Then review warnings — some are important (like a zero timeout in a production config) and some are informational (like an unknown field you added intentionally for a custom interceptor).
3. Once the status bar is green, visually scan the Fields table to confirm every field has the type and value you intended.
4. Copy the validated JSON from the text area and paste it back into your code with confidence.

Worked Examples

Example 1: Minimal valid request config

Paste this config:

{"url": "https://api.example.com/users"}

Expected result: green status bar. Method is inferred as GET (the Axios default). The Fields table shows one field: url, type string, status "known". This is the minimum valid Axios request config.

Example 2: Wrong field name — baseUrl instead of baseURL

Paste this config:

{"baseUrl": "https://api.example.com", "url": "/users"}

Expected result: yellow status bar (valid with warning). The warning panel will note that baseUrl is an unknown field — Axios uses baseURL (uppercase URL). The Fields table will show baseUrl with status "unknown". Fix:

{"baseURL": "https://api.example.com", "url": "/users"}

Re-validate: the warning disappears and both fields now show status "known".

Example 3: Auth field with wrong shape

Paste this config:

{"url": "https://api.example.com/data", "auth": "alice:password123"}

Expected result: red status bar. Error: "Field 'auth' must be an object." The auth field is a string, but Axios expects an object with username and password properties. Fix:

{"url": "https://api.example.com/data", "auth": {"username": "alice", "password": "password123"}}

Re-validate: the error is gone, the Fields table shows auth as an object with type "object" and status "known".

Example 4: Headers as an array instead of an object

Paste this config:

{"url": "https://api.example.com/users", "headers": ["Content-Type: application/json"]}

Expected result: red status bar. Error: "Field 'headers' must be an object." Headers must be a plain object ({"Content-Type": "application/json"}), not an array. Fix:

{"url": "https://api.example.com/users", "headers": {"Content-Type": "application/json"}}

Re-validate: green status bar. The Fields table now shows headers as an object.

Example 5: Invalid method string

Paste this config:

{"url": "https://api.example.com/users", "method": "fetch"}

Expected result: red status bar. Error: "Invalid HTTP method: 'fetch'." Axios does not recognise "fetch" as an HTTP method. Replace it with a valid method:

{"url": "https://api.example.com/users", "method": "get"}

Re-validate: green status bar. The Method stat card now shows "get" (Axios accepts lowercase method strings).

Example 6: Complete, well-formed POST config

Paste this config:

{
  "url": "https://api.example.com/users",
  "method": "post",
  "headers": {
    "Content-Type": "application/json",
    "Authorization": "Bearer eyJhbGci..."
  },
  "data": {"name": "Alice", "email": "[email protected]"},
  "timeout": 10000
}

Expected result: green status bar. All five fields — url, method, headers, data, timeout — show as "known" in the Fields table. The Method card shows "post", the URL card shows the endpoint. This is a clean, ready-to-use Axios config.

Tips and Shortcuts

• Keyboard shortcut. Press Ctrl+Enter (Windows/Linux) or ⌘+Enter (macOS) to validate without clicking the button. This is faster when iterating on a config with multiple edits.
• Load from a file. If you have a .json file with an Axios config, drag it onto the drop zone. The file content is loaded into the text area and validated without copy-pasting.
• Use samples to learn. The sample chips — ✓ Valid Request, ⚠ Bad Request, ✓ Valid Response, ⚠ Bad Response — load realistic examples. Validate the "Bad" samples first to see what error output looks like, then validate the "Valid" samples to see a clean result.
• Credentials are safe. The tool processes configs entirely in JavaScript running in your browser tab. API keys, bearer tokens, and passwords in your headers or auth fields are never transmitted anywhere.
• JSON formatting. The text area accepts both compact and formatted JSON. If your config is not valid JSON (single quotes, unquoted keys, trailing commas), the validator will report a JSON parse error and highlight that the input needs to be corrected before field-level validation can run.
• Read the complete guide. For a full explanation of what each field does, how Axios interprets it, and the best practices around auth, timeout, and response type, see The Complete Guide to Axios Validating.