After this lesson, you will be able to: Use Burp Repeater as the core manual-testing tool: send requests to it, modify parameters/headers/cookies/body, read responses, and manually find a SQL injection point without automation.
Repeater is where manual web testing happens. This lesson teaches the Repeater workflow (send, modify, resend, read) and applies it to manually confirm a vulnerability, building the habit of understanding a bug by hand before reaching for automation.
Repeater holds a single request you can edit and resend endlessly while reading the full response. The workflow: find an interesting request in History or Intercept, send it to Repeater (right-click > Send to Repeater, or Ctrl+R), modify something (a parameter, header, cookie, or the body), click Send, and read how the response changed. Repeat. This tight loop is how you probe a suspected vulnerability precisely.
In Repeater you can change any part of the request: parameter values, header values, cookies, the HTTP method, the body. The response pane offers raw, pretty, and rendered views. Watch the status code, the response length, and the body content as you change one input at a time. Changing one thing per send is the discipline that lets you attribute a response difference to a specific cause.
Repeater supports multiple tabs so you can keep several requests organized during an engagement (a login, a profile fetch, a search). You can also send two responses to Comparer to diff them. Keeping requests in labeled tabs is how professionals stay oriented when testing a complex flow.
Use a PortSwigger SQL injection lab. No automated tools.
1. In the lab, find a request with a parameter that reaches the database (e.g. a product category filter).
2. Send it to Repeater (Ctrl+R).
3. Append a single quote (') to the parameter value and Send. An error or changed response suggests injection.
4. Try a boolean test: ' OR '1'='1 vs ' AND '1'='2 and compare the responses.
5. Confirm the injection manually from the response differences, then read PortSwigger's solution to check your reasoning. You found it without any automation.
Pick the best reason.
Changing several inputs at once and losing the cause. Reading only the rendered view and missing details in the raw response. Ignoring response length as a signal. Not using tabs, then losing track of which request is which. Jumping to automated tools before understanding the bug by hand. Forgetting to URL-encode payloads where the context requires it.
Sign in and purchase access to unlock this lesson.