SP Params vs JSON
Check a stored procedure call against a JSON body: missing keys, extra keys, wrong types.
Runs fully in your browser. Nothing you paste here is sent anywhere.PrivateStored procedure
JSON body
Parameters
About this tool
Paste the stored procedure call that works in the database on the left and the JSON body your service receives on the right. Each @parameter is matched to a key of the same name and the result is listed parameter by parameter: missing in the JSON, present in the JSON but not taken by the procedure, a type mismatch such as "100.00" sent as text where the call passes a number, or the same type with a different value. Click a row to bring it into view in both editors.
The SQL side can be an EXEC call, a bare list of @name = value pairs, or a CREATE PROCEDURE signature, where the declared types are checked instead: an int receiving a string, a varchar(10) receiving eleven characters, a datetime receiving something that is not a date. A variable passed as a value takes its type from a DECLARE earlier in the script; one with no DECLARE is reported as not comparable rather than as a match. Numbers are compared by value, so 100.00 equals 100.
The options cover how real payloads differ from the SQL: "Ignore @" matches @s_ssn with s_ssn, "Ignore case" matches @i_SecCabecera with i_seccabecera, and "Ignore OUTPUT" leaves out the parameters the procedure returns. When a name is missing on one side and a close spelling is left over on the other, the row suggests it. The missing parameters can be copied as JSON properties, and the extra keys as aligned @name = value arguments.
Nothing you paste is transmitted. The page is static HTML and both parsers run in your tab, so production calls, account numbers and customer names in a test payload stay on your device.
Frequently asked questions
Is my SQL or JSON uploaded anywhere?
No. The procedure call and the JSON are parsed and compared by JavaScript in your browser, and the page has no backend to send them to. It keeps working with the network disconnected.
What does "Ignore @" do?
SQL Server parameters start with @ and JSON keys usually do not. With the option on, @s_ssn and s_ssn are the same name; with it off, the JSON key has to be "@s_ssn" to match. It applies to both sides, so a body that already uses @-prefixed keys matches either way.
Why is a parameter marked "Not comparable"?
Because the call passes a variable or an expression, such as @s_date = @w_fecha or getdate(), and its value is only known when the script runs. The parameter is present on both sides, but its value cannot be checked. If the variable is declared in the pasted script, its type is still checked.
Which SQL dialects does it read?
T-SQL as SQL Server and Sybase write it: EXEC and EXECUTE, N'…' strings, bracketed names, OUT and OUTPUT flags, comments and DECLARE lines. Positional arguments are counted but cannot be matched, since they have no name. Oracle and PostgreSQL named-argument syntax (=> and :=) is not read yet.
Does it compare nested JSON?
Parameters are matched against the top-level keys of the object, which is how a body is mapped onto a procedure call. A nested object or array arriving where the call passes a scalar is reported as a type mismatch.