JSON Escape Character Repair Prompt Template

This prompt is for platform engineers and API gateway operators who receive model-generated JSON payloads that are structurally intact but contain unescaped characters—unescaped double quotes inside string values, stray backslashes, or raw control characters—that cause standard JSON parsers to throw fatal errors. The job is not to re-generate the JSON or guess the intended schema, but to surgically repair the escape sequences so the payload becomes valid, parseable JSON without altering the semantic content. Use this prompt when the model output is almost correct and you need a fast, deterministic repair before the payload enters a downstream system, database, or user-facing surface.

This prompt is appropriate when you have a single, self-contained JSON text that fails parsing with a specific character-position error. It is not a replacement for schema validation, type coercion, or field-level correction. Do not use this prompt when the JSON is structurally malformed (missing braces, wrong brackets, or broken nesting), when the payload is truncated by token limits, or when the model has hallucinated entire fields that need to be removed. The prompt assumes the original intent is recoverable and that the repair should be conservative—only fixing escape sequences, not rewriting values. In high-stakes pipelines where a bad repair could corrupt financial records, clinical notes, or legal text, always pair this prompt with a round-trip comparison check that verifies the repaired JSON, when re-serialized, matches the original semantic content.

Before wiring this into a production harness, define your tolerance for false positives. Aggressive unescaping can corrupt intentionally escaped sequences, while conservative repair may leave edge cases unresolved. Start by logging every repair event with the original payload, the repaired payload, and the specific character positions changed. Run a batch of known-broken and known-valid JSON samples through the prompt and measure precision (did we only fix what was broken?) and recall (did we fix all breakage?). If your pipeline processes user-generated content or free-text fields that legitimately contain quotes and backslashes, add a human-review escalation path for repairs that modify more than a configurable threshold of characters. The next section gives you the exact prompt template to adapt and deploy.

This template provides a direct, instruction-only prompt for repairing a JSON payload that is structurally valid but contains unescaped characters—such as double quotes within string values, unescaped backslashes, or raw control characters—that cause standard parsers to fail. It is designed to be dropped into a post-generation repair loop where the input is a malformed JSON string and the expected output is a clean, parseable JSON object. The prompt instructs the model to act as a precise repair tool, not a conversational assistant, and to return only the corrected JSON without explanation or markdown wrapping.

textCopy
You are a JSON repair tool. Your only job is to fix escape character errors in the provided JSON string and return a valid, parseable JSON object.

[CONSTRAINTS]
- Return ONLY the repaired JSON object. Do not include any explanation, markdown fences, or surrounding text.
- Preserve all original keys, values, and data types exactly as intended. Do not change, summarize, or omit any content.
- Escape all unescaped double quotes (") inside string values by replacing them with \".
- Escape all unescaped backslashes (\) inside string values by replacing them with \\.
- Replace any raw control characters (e.g., newlines, tabs within string values) with their proper escape sequences (\n, \t, etc.).
- If the input is already valid JSON, return it unchanged.
- If the input is so malformed that the intended structure cannot be determined, return the JSON object: {"error": "unrepairable", "reason": "[BRIEF_REASON]"}.

[INPUT]
[MALFORMED_JSON_STRING]

To adapt this template, replace [MALFORMED_JSON_STRING] with the raw string that failed parsing. The [CONSTRAINTS] section can be tightened for specific failure modes you observe in production—for example, if your pipeline only ever sees unescaped quotes, you can simplify the instructions to focus on that single repair. If you are using a model with a JSON mode or structured output feature, you can replace the final constraint with a request to match a specific [OUTPUT_SCHEMA]. Always test the repaired output by running it through your application's JSON parser before returning it to the calling system. If the repair fails, log the original malformed string and the model's response for later analysis.

The JSON Escape Character Repair prompt is designed to sit inside a post-generation repair loop—a dedicated step in your inference pipeline that runs after the primary model response but before the output is passed to a downstream parser, database, or API. This is not a prompt you expose directly to end users. Instead, it should be called programmatically by an application service whenever a JSON validator rejects a model-generated payload with a parsing error. The repair prompt receives two critical inputs: the original malformed JSON string and, optionally, the specific parser error message. Providing the error message significantly improves repair accuracy because it tells the model exactly where and why the parser failed, rather than forcing it to scan the entire payload blindly.

Integration pattern: Wrap the repair call in a retryable function with a strict schema validator as the gate. The flow should be: (1) Primary model generates output. (2) Application attempts JSON.parse() or equivalent. (3) If parsing succeeds, proceed. (4) If parsing fails, capture the error message and call the repair prompt with [MALFORMED_JSON] and [PARSER_ERROR]. (5) Validate the repaired output. (6) If still invalid, retry once with the new error message. (7) If retry fails, log the original and repaired payloads, increment a failure metric, and either fall back to a safe default or escalate for human review. Never silently drop the payload—corrupted JSON often contains recoverable data, and the failure itself is a signal that your primary prompt or model needs attention.

Validation and eval checks: After the repair prompt returns, you must run at least three checks before accepting the output. First, structural validity: parse the repaired JSON string and confirm no exceptions are thrown. Second, round-trip fidelity: re-serialize the parsed object to a compact JSON string and compare key structural properties (top-level keys, array lengths, value types) against a best-effort parse of the original malformed input. Third, no silent data loss: if the original string contained a known set of expected fields or values, verify they are present in the repaired output. For high-risk pipelines, add a fourth check—human review gating—where any repair that modifies more than a configurable threshold of characters (e.g., 5% of the string) is flagged for manual inspection before proceeding.

Model choice and latency budget: This repair task is well-suited to fast, instruction-following models like GPT-4o-mini, Claude 3.5 Haiku, or Gemini 1.5 Flash. The prompt is a single-turn string transformation with no tool calls or retrieval, so latency should be under 500ms in most deployments. If your primary generation already uses a large model, avoid routing the repair through the same model tier—use a smaller, cheaper model for the repair loop to keep costs and latency predictable. Set a client-side timeout (e.g., 2 seconds) and treat timeouts as failures that trigger the same retry-and-escalate path as invalid outputs.

Observability and debugging: Log every repair attempt with structured metadata: the original error type, the number of characters changed, the repair model used, latency, and whether the repair succeeded or failed. This data is invaluable for detecting systemic issues—if you see a spike in unescaped quotes from a specific primary prompt or model version, you can fix the root cause rather than relying indefinitely on the repair loop. Tag all repair events with a repair_attempt flag in your tracing system so you can distinguish between clean generations and repaired ones when analyzing production quality. Finally, never discard the pre-repair payload; store it alongside the repaired version for at least the retention window of your debug logs so you can replay and improve the repair prompt over time.