Single Quote to Double Quote Conversion Prompt for JSON

This prompt is designed for backend engineers and platform teams who need to repair model-generated JSON payloads that use single quotes or mixed quoting styles instead of the JSON-standard double quotes. The job-to-be-done is a deterministic, post-generation repair step: take a malformed string that is semantically a JSON object, fix the quoting to produce a strictly valid application/json payload, and return the corrected string. The ideal user is an integration engineer building a data pipeline, an API gateway operator, or a developer maintaining an agent loop where a model consistently outputs single-quoted JSON despite schema instructions.

Required inputs for this prompt are the raw, malformed string ([MALFORMED_JSON]) and, optionally, an expected [OUTPUT_SCHEMA] for structural validation after repair. The prompt works best when the input is almost valid JSON—the structure, brackets, and keys are correct, but the string delimiters are wrong. It handles nested quotes, apostrophes within values (e.g., 'O'Reilly'), and escaped sequences that need conversion. Do not use this prompt when the input is completely unstructured free text, when the JSON structure itself is broken (missing braces, unbalanced brackets), or when the quoting style is intentional (e.g., a Python dict literal that should remain as code). For structural damage, use the sibling JSON Repair Prompt Template for API Payloads or Bracket and Brace Balancing Prompt instead.

This prompt is a post-generation repair tool, not a schema enforcer. It assumes the model intended to produce valid JSON but used the wrong string delimiter. If the model is hallucinating keys, inventing values, or violating a target schema, pair this prompt with the Schema Validation Failure Repair Prompt after quoting is fixed. Always run the output through a strict JSON parser (JSON.parse or equivalent) as a validation gate. If the parse fails, the repair was incomplete, and you should either retry with more context or escalate the malformed input for human review. For high-throughput pipelines, log the repair rate and diff the input against the output to detect silent corruption.

This prompt template is designed to be dropped into your application's repair layer whenever a model output fails JSON parsing due to single quotes or mixed quoting styles. It accepts the malformed string, optional context about the expected structure, and a set of constraints that define how to handle edge cases like apostrophes in values, escaped sequences, and nested quotes. The template is self-contained—you can copy it directly into your codebase, wire it into a retry loop, and add validation gates before the repaired output reaches downstream systems.

textCopy
You are a JSON repair specialist. Your only job is to convert a malformed JSON string that uses single quotes or mixed quoting styles into a strictly valid JSON string that uses double quotes for all keys and string values.

## Input
[MALFORMED_JSON]

## Expected Schema (Optional)
[EXPECTED_SCHEMA]

## Constraints
- Replace all single-quoted keys and string values with double-quoted equivalents.
- Do not modify apostrophes inside string values (e.g., "don't" stays as "don't").
- Preserve all escaped sequences that are already valid JSON escape sequences.
- Convert single-quote escape sequences (\') to double-quote escape sequences (\") only when they appear inside string delimiters.
- Do not change numeric, boolean, or null values.
- Do not add, remove, or reorder fields.
- If the input contains unescaped double quotes inside single-quoted strings, escape them properly in the output.
- If the input is already valid JSON with double quotes, return it unchanged.
- If the input is irrecoverably malformed (e.g., missing closing brackets, impossible nesting), output a JSON object with an "error" field describing the problem and a "partial_result" field containing the best-effort repair.

## Output Format
Return ONLY the repaired JSON string with no markdown fences, no explanatory text, and no additional commentary. If repair is impossible, return a JSON object:
{
  "error": "<description>",
  "partial_result": "<best_effort_output_or_null>"
}

## Examples

Input: {'name': 'John', 'message': 'It\'s ready'}
Output: {"name": "John", "message": "It's ready"}

Input: {'key': 'value with \"nested\" quotes'}
Output: {"key": "value with \"nested\" quotes"}

Input: {unclosed
Output: {"error": "Unclosed object at position 9", "partial_result": null}

To adapt this template, replace [MALFORMED_JSON] with the raw string that failed parsing. If you have a target schema, populate [EXPECTED_SCHEMA] with the JSON Schema or a natural-language description of expected fields and types—this helps the model disambiguate structural intent when the quoting is ambiguous. The examples section demonstrates the three most common failure patterns: apostrophes in values, nested escaped quotes, and irrecoverable structural breaks. You can extend the examples with patterns specific to your application's failure modes. After the model returns a result, always run it through a JSON parser as a validation gate before accepting the repair. If the repair itself fails parsing, increment a retry counter and re-invoke with the parser error message appended to [MALFORMED_JSON]. Stop retrying after three attempts and escalate to a human review queue or a dead-letter topic for manual inspection.

This prompt is designed as a post-generation repair step, not a standalone utility. It should be invoked only after a model output fails JSON parsing due to single-quoted strings or mixed quoting styles. The typical integration point is inside a validation retry loop: the primary model generates a response, a JSON parser attempts to parse it, and on failure the output is routed to this repair prompt before a final parse attempt. Do not run this prompt on every output—it adds latency and cost, and well-formed JSON should pass through without repair.

The implementation harness requires three components: input sanitization, prompt execution with a repair-specific model, and output validation. For input sanitization, strip any markdown code fences or surrounding explanatory text before passing the raw malformed JSON string as [MALFORMED_JSON]. Use a fast, cheaper model for the repair call (e.g., GPT-4o-mini, Claude Haiku, or a fine-tuned small model) since quote conversion is a syntactic task that doesn't require deep reasoning. Set temperature=0 and top_p=1 to maximize deterministic behavior. After receiving the repaired output, run it through JSON.parse() or your language's equivalent. If parsing fails again, increment a retry counter and re-invoke the prompt with the new error message appended to the input context. Stop after 3 retries and escalate to a dead-letter queue for manual review.

Logging and observability are critical here because quote repair failures often signal deeper problems—the model may be generating non-JSON content, hallucinating fields, or hitting token limits that corrupt structure. Log the original malformed string, the repaired string, parse success/failure, retry count, and the model used. Tag these events with a repair_stage: quote_conversion label so you can distinguish quote-related failures from schema mismatches or truncation. If your pipeline processes more than 5% of outputs through this repair step, investigate the upstream prompt's JSON formatting instructions—the root cause is likely insufficient schema constraints or missing explicit double-quote requirements in the system prompt.

For high-throughput pipelines, consider batching repair requests or implementing a fast-path check: scan the raw string for single quotes around keys or string values before invoking the LLM. A simple regex like /'[^']*'\s*:/ can detect single-quoted keys, and if absent, skip the repair call entirely. This reduces unnecessary LLM invocations. For regulated or audit-sensitive data, ensure the repair prompt runs in the same trust boundary as the primary model and that repaired outputs are logged immutably. Never silently fix and forward—downstream systems should be able to trace that a repair occurred and inspect the original malformed output.