Convert code to another language
Idiomatic output in the target language, followed by every behaviour difference it introduces — overflow, error propagation, integer division.
Last updated
Fill in the blanks
Assembled in your browser — nothing you type is stored or sent anywhere.
Your prompt
Model-agnostic — works in Claude, ChatGPT, Gemini or any AI chat.
Why this prompt works
- →Asking for idiomatic code instead of a transliteration prevents JavaScript-shaped Python (or the reverse) — code that runs but reads as a translation rather than native code.
- →Requiring an explicit list of behaviour differences surfaces exactly the bugs silent conversions cause: a float that overflows differently, an error swallowed instead of thrown, division that truncates where the original didn't.
- →Flagging logic with no clean equivalent stops the conversion from quietly reinterpreting a language-specific idiom into something that merely looks similar but behaves differently.
Part by part
- written idiomatically for that language — not a line-by-line transliteration
- The distinction that makes the output usable. Transliterated code compiles and reads as foreign, and it carries the source language's assumptions with it.
- list every behaviour difference this introduces
- The section that matters more than the code. A conversion that runs and behaves differently is worse than one that fails to compile.
- numeric precision and overflow handling
- The most common silent difference. Integer width, overflow behaviour and float precision vary between languages and none of it surfaces until the values are large.
- how errors or exceptions propagate
- Languages disagree fundamentally here — exceptions, return values, panics — so control flow rarely survives conversion unchanged.
- say so and explain the closest approximation
- Prevents the worst outcome: logic with no clean equivalent being silently changed into something that looks right and is not.
Common mistakes
Convert this Python to JavaScript.Produces working code and no account of what changed. Integer division, dictionary ordering and exception semantics all differ, and each one is a bug that appears later with no obvious connection to the conversion.
Rewrite this in Go, keeping it as close to the original as possible.Asking for closeness produces transliteration, which fights the target language. Code written against Python's exception model in Go is verbose, unidiomatic and wrong about error handling.
Convert this and make sure it works.Works is only checkable against tests the model does not have. Without the differences enumerated, you cannot even write the tests that would confirm it, because you do not know what to test for.
Questions
Which differences bite most often?
Integer division and overflow, string encoding and indexing, whether collections preserve insertion order, and how errors propagate. Each is invisible in small examples and each changes results at scale.
Should I trust the converted code?
As a starting draft. It is generally correct in structure and frequently wrong at the edges, so it needs the same tests the original had — which is the strongest argument for having them before converting.
What about converting to a language I do not know?
That is where the differences list matters most, since you cannot spot the unidiomatic parts yourself. Read it before the code, and treat anything it flags as unresolvable as work that needs a person who knows the target.
Does this work for a whole project?
No. It works function by function and module by module, where the surface is small enough to enumerate differences honestly. Project-scale conversion is architecture, and the interesting decisions are ones no prompt can make.