Prompt Injection Tester
Harden your own LLM apps against prompt injection. Generate a labelled suite of injection test cases — instruction override, role manipulation, delimiter escape, encoding, indirect (via retrieved content and tools) and exfiltration — to run against your model, and scan your own system prompt for weak patterns with concrete fixes. Aligned with OWASP LLM01. Runs entirely in your browser — no LLM is called and nothing is uploaded.
Defensive use only. This runs entirely in your browser — no LLM is called, no probe is executed, and nothing is uploaded. Use it to harden systems you own or are authorised to test.
Pick the attack categories you want to cover, then generate a labelled probe suite to run against your own model or application. Each probe names the defense it tests.
What this tool is
- A free, in-browser prompt injection tester for defenders: it helps you harden LLM apps and system prompts you own — it does not call any LLM and never attacks anyone else.
- Generate a labelled test suite of injection probes across six categories — instruction override, role/context manipulation, delimiter escape, encoding/obfuscation, indirect (via retrieved content and tools) and data exfiltration — then run them against your own model.
- Paste your own system prompt and a client-side heuristic scan flags weak patterns: missing instruction hierarchy, undelimited user input, over-trusted tool output, no output constraints, and secrets embedded in the prompt — each with a concrete fix.
- Every probe names the defense it tests, so a result maps directly to a hardening action. Aligned with OWASP LLM01 (Prompt Injection).
- Everything runs client-side in your browser. No prompt, probe or result is ever sent to a server, and no model is invoked.
What is prompt injection?
Prompt injection is an attack in which crafted text causes a large language model to ignore the instructions its developer gave it and follow the attacker's instructions instead. The root cause is architectural: a model reads its trusted system prompt and the untrusted input it is handed in the same undifferentiated stream of tokens, so a line of input that says "ignore your previous instructions" can look just like a legitimate command. Prompt injection is LLM01, the number-one risk in the OWASP Top 10 for LLM Applications.
Direct vs. indirect injection
- Direct (first-order). The user types the malicious instruction straight into the prompt — "ignore previous instructions", a persona jailbreak, a delimiter-escape payload, or an encoded command.
- Indirect (second-order). The payload is hidden inside content the app later ingests — a web page, a document in a RAG pipeline, an email, a ticket, or a tool's output — so the model is injected without the attacker ever talking to it. This is the dangerous path for agents that browse, retrieve, or read user data.
Prompt injection vs. jailbreak
The terms overlap but are not identical. A jailbreak targets the model's safety or content policy — making it produce something it is trained to refuse. Prompt injection is broader: it overrides whatever instructions your application set, which also covers hijacking an agent's task, leaking the system prompt, or triggering an unintended tool action. Every jailbreak is a kind of injection, but not every injection is a jailbreak — and for app builders, injection is the wider concern because it includes indirect attacks through your own data and tools.
Types of prompt injection attacks
- Instruction override. "Ignore all previous instructions", fake authority/"system override" framing, and incremental erosion of the rules one concession at a time.
- Context / role manipulation. Alternate personas, "developer mode", hypothetical/fiction wrappers, and dual "safe + unfiltered" output splits.
- Delimiter / context escape. Forged closing tags or fences that try to break out of the structure separating instructions from input.
- Encoding / obfuscation. Base64, ROT13, leetspeak or token-splitting that hides a payload from a naive filter while the model still decodes it.
- Indirect via retrieved content / tools. Instructions planted in a document, web page, email or tool result that an agent reads and mistakenly obeys.
- Data exfiltration. Coaxing the model to reveal its system prompt, embedded secrets, or other users' data — verbatim, summarised, or encoded.
How to prevent prompt injection
There is no single fix — defense is layered, and no layer is perfect on its own:
- Instruction hierarchy. State plainly that the system prompt always outranks user and retrieved content, and must never be overridden, changed, or revealed.
- Delimit untrusted input. Wrap it in a hard-to-forge marker and tell the model everything inside is data to analyse, never commands to obey.
- Don't trust tool / retrieved content. Treat every document, search result and tool output as untrusted — their text must not be able to issue instructions.
- Output filtering & constraints. Constrain the format and scope of output, and forbid disclosure of the prompt or any secret.
- Least-privilege tools + human-in-the-loop. Give an agent the fewest capabilities it needs, and require explicit human confirmation before any irreversible or externally-visible action.
- Keep secrets out of the prompt. If there is nothing sensitive in context, there is nothing to exfiltrate. Fetch secrets server-side at call time.
Defensive scope: this tester is for hardening systems you own or are explicitly authorised to test. The probes are benign, well-known red-team templates — the tool never executes them, never calls a model, and provides no guidance for attacking third-party systems. Treat the weakness scan as a heuristic starting point, not a proof of safety: always confirm behaviour by running the generated suite against the live system.
Frequently asked questions
What is prompt injection?
Prompt injection is an attack where crafted text makes a large language model ignore or override the instructions its developer gave it, and instead follow the attacker’s instructions. Because an LLM processes its system prompt and the untrusted input it receives in the same stream of text, input that says something like "ignore your previous instructions and do X" can be mistaken for a legitimate command. The consequences range from leaking the hidden system prompt or secrets, to producing disallowed output, to — in an agent with tools — taking real actions such as sending email or calling an API. It is the top entry (LLM01) in the OWASP Top 10 for LLM Applications.
What are the types of prompt injection attacks?
They fall into two broad classes. Direct (first-order) injection is when the user themselves types the malicious instruction into the prompt — "ignore previous instructions", persona jailbreaks, delimiter-escape payloads, and encoded (Base64/ROT13/leetspeak) instructions. Indirect (second-order) injection is when the payload is hidden inside content the application later ingests — a web page, a document in a RAG pipeline, an email, a support ticket, or a tool’s output — so the model is injected without the attacker ever talking to it directly. Within those classes, common techniques are instruction override, role/context manipulation, delimiter or context escape, encoding/obfuscation, and system-prompt or data exfiltration. This tool generates probes for each category.
What is the difference between prompt injection and jailbreaking?
They overlap but are not the same. Jailbreaking specifically targets the model’s safety or content policy — getting it to produce output it is trained to refuse, usually via persona tricks or hypothetical framing. Prompt injection is broader: it is about overriding the application’s instructions, whatever they are. A jailbreak is one kind of prompt injection (it injects "ignore your safety rules"), but injection also covers hijacking an agent’s task, exfiltrating a system prompt, or making a tool-using agent take an unintended action — none of which are about the base safety policy. For a defender building an app, injection is the wider concern because it includes indirect attacks through your data and tools.
How do you prevent prompt injection?
There is no single fix; defense is layered. Establish a clear instruction hierarchy and tell the model its system instructions always outrank user and retrieved content. Delimit untrusted input with hard-to-forge markers and state that everything inside is data, not commands. Treat all tool output and retrieved documents as untrusted — never let their text issue instructions. Constrain output and forbid disclosure of the prompt or secrets. Apply least privilege to tools and require human confirmation before any irreversible or externally-visible action. Filter and validate output, and keep secrets out of the prompt entirely so there is nothing to exfiltrate. Finally, test continuously with a probe suite — which is what this tool’s generator is for.
Does this tool call an AI model or send my prompt anywhere?
No. It is 100% client-side. The probe library is a static, built-in set of benign red-team test templates, and the weakness scanner is a local string/heuristic pass over text you paste. No LLM is invoked, no probe is executed, and nothing — your system prompt, the generated suite, or the scan results — ever leaves your browser. It is designed for hardening systems you own or are authorised to test; it provides no instructions for attacking third-party systems.