jsonlint is converting a decimal field having "0.0" to a int "0", please see input output below.

I know technically 0.0 and 0 are equal but that's something my application should handle , Jsonlint should give me output after format as is without any change in its values.

input
{"Discount":0.0}

output
{
"Discount": 0
}

Hey guys,

I noticed earlier that supporting large numbers doesn't work ok when I attempt to format JSON (looks to be falling under the JavaScript large numbers arithmetic overflow issue).

Would you accept a PR for this issue?

If jsonlint is stateless and completely implemented in the client, what is keeping it from enabling itself to be launched offline? Its <html/> already even has a manifest attribute, suggesting that this was the intention…

According to http://json.org/ this is NOT correct yet it validates by jsonlint
{ "test": "" }

It also incorrectly validates other invalid escape sequences.
Example, this is not a valid JSON escape sequence but it validates
{ "test": "\h" }

Generally accepted best practice is to identify one's service (and associated reporting mechanisms) by setting a unique and informative user agent string. Currently, the jsonlint.com online validator uses only "-".

I have a site where people can submit json data which uses php. I can tell the user when it's invalid and link them to lint, but it would be great if I can link them to a pre-populated lint (perhaps via a post request).

Is there any current way to do this, or do they have to paste the json into lint themselves?

Refer to: https://tools.ietf.org/html/rfc7159#page-13

Steps to reproduce:

1. Enter http://jsonlint.com/
2. Type "This is a valid string" and click "Validate".

Expected result: Validation succeeded message.
Actual result:
"Parse error on line 1:
"anythingisvalid"
^
Expecting '{', '['"

The following JSON is invalid, but it is accepted by JSONLint:

{
  "@context": {},
  "@id": "id1",
  "@id": "id2",
  "@type": "type1",
  "@type": "type2"
}

You can see another validator complaining: http://www.freeformatter.com/json-validator.html

This evaluates as valid JSON, but it's invalid: "\n".

Just try JSON.parse('"\n"').

Extremely useful tool, thanks.

Please could you add a facility to batch validate JSON files?

In javascript it's a legal object to have the key without quotations. Is this something that you can support, maybe as an option?

{
    "myNum": [1, 2]
}

JSON-LD allows for having multiple identical attributes. Currently, the linter is removing these attributes.

http://json-ld.org/

It used to be this would be a full-screen page with a single textbox and a lint button - now it is redirecting to https://jsoncompare.com/#!/simple/ which has more bells/whistles.

Could it at least redirect to https://jsoncompare.com/#!/simple/fullscreen/ ?

Example "crets" : ISODate("2011-02-09T21:59:07.183Z") construct should not be considered as syntax error in json validation.

-David

I was validating a eslint json config like this:

{
  "parserOptions": {
    "ecmaVersion": 6,
    "sourceType": "module"
  },
  "rules": {
    "semi": 0,
    "indent": ["warning", 2],
    "comma-dangle": ["error", "always"],
    "no-unreachable": "error",
    "curly": 1,
    "block-scoped-var": 2,
    "no-else-return": 1,
    "no-use-before-define": 2,
    "no-undef": 2,
    "no-var": 2,
    "no-duplicate-imports": 2,
    "no-const-assign": 2,
    "no-dupe-class-members": 2,
    "no-labels": 2,
    "no-extra-parens": 1,
    "indent": 1,
    "no-mixed-spaces-and-tabs": 1,
    "camelcase": 1,
    "prefer-const": 1,
    "max-len": [2, 100],
    "max-statements": [2, 50],
    "no-unused-vars": ["error", { "vars": "all", "args": "none" }]
  },
  "env": {
    "node": true
  }
}

The indent property is defined twice. It is indeed a valid JSON file, but it would be nice if it threw a warning it.

The original pro.jsonlint.com was radically better than the newly-redirected jsoncompare.com. Can we get the original source code (or the original site) back up? If you guys aren't interested in continuing to maintain it, I'd be happy to take a stab at it, just to keep that original site up.

Lone surrogate code units should be left escaped in the pretty printed JSON, and should not be literally displayed in the browser.

The JSON pretty printer does a good job at deciding when to decode escaped Unicode characters into the literal character and when not to (for example, compare the pretty printing of ["\u0030"] vs. ["\u0000"]).

In Chrome, if I validate JSON with a lone surrogate code unit ["\ud800"] I see what looks like:

[
    "
]

The pretty-printed output should be copy-pastable JSON, but copy-pasting this instead pastes the Unicode Replacement character � between quotation marks.

Instead, the above should pretty print as:

[
    "\ud800"
]

(Amazingly I can copy-paste U+D800 from Internet Explorer into Word, which is pretty impressive considering a lone surrogate isn't a real Unicode code point.)

The following JSON is reported as valid by JSONLint:

{
"a": {},
"a": {}
}

This JSON has two properties in an object that have the same identity. IMHO JSONLint should report this as malformed.

It is truncating large long values. You can parse the following JSON Object and compare the values

{"large_long_a":288536860722989048,"string":"2013-10-30 03:41:10","large_long_b":288517478611921009}

The old pro.jsonlint.com used to be able to have multiple linters open at once on one page. Now I have to have a tab for every chunk of JSON that I want to look at, which makes it hard to remember which tab is the correct one for what I'm looking for. Reintroducing this functionality would be awesome!

Also on a side note, I really liked the fact that the old site was full screen and beautified your tabs by default, but it is not the biggest deal having to choose those options.

I have given your validator to a client to check their JSON files. Your validator says they are ok when they are not.

Your validator converts hidden characters to tabs. Even when those characters are invalid.

I have attached a zip with a JSON file with invalid indenting characters that your validator says it's ok.

error.json.zip

This "{"foo":t rue}" evaluates as valid JSON, but it's invalid.

Try JSON.parse("{"foo":t rue}")

autofocus in the main text input when the page loads would be nice! :)

Thanks for the great tool!

i wonder how many people actually type their json strings to validate them and how many paste strings from some other source either to validate them or properly indent them ? For the latter, clicking on validate button every time becomes repetitive pretty quickly...

Autovalidation would be really welcome! Or at least a keyboard shortcut

Thanks in advance

Received email feedback:

JSONLint expects [ or { in a JSON text first. http://zaach.github.io/jsonlint does not and seems to comply to the standard: http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf

To test, try this:

{
    "pattern": "^((?:\.??\/)??[A-Za-z0-9_\&\-\/\.\?\=]*?)$"
}

You get back results:

Parse error on line 2:
{    "pattern": "^((?:\.??\/)??[A-Za
----------------^
Expecting 'STRING', 'NUMBER', 'NULL', 'TRUE', 'FALSE', '{', '['

JSLint reports this as valid JSON.

The UTF-8 whitespace character EM SPACE (U+2003, e2 80 83 in UTF-8) is an illegal character between json terms. See any vintage of the json RFC, which says:

   Insignificant whitespace is allowed before or after any of the six
   structural characters.

      ws = *(
              %x20 /              ; Space
              %x09 /              ; Horizontal tab
              %x0A /              ; Line feed or New line
              %x0D )              ; Carriage return

That means the only legal whitespace characters are a subset of the ascii whitespace characters.

Even though json allows UTF-8 characters, that does not mean that you can put any UTF-8 character between json terms. Putting an EM SPACE between terms is conceptually similar to putting, say, a z between json terms.

Here is a simple example of json with an EM SPACE after each comma:

[1, 2, 3]

jsonlint.com reports that as valid json. The linter should report that as invalid json. Why is that important? If you are using Ruby on Rails and Rails spits out an error due to an unexpected token when parsing json with an EM SPACE between terms, and then you check with a jsonlinter as the authority on what is legal json, and the linter says the json is legal, you might end up tearing all your hair out trying to find the bug in your Rails program. Other jsonlinters correctly report the json as invalid.

If instead of the valid JSON

{
"key1": [
"key2",
"key2 value with spaces"
]
}

we instead ask JSONlint to validate

{
"key1": "[
"key2",
"key2 value with spaces"
]"
}

we are duly informed that the " before [ is an error, but with that validation we see also that JSONlint has collapsed the value

"key2 value with spaces"

to

"key2valuewithspaces"

--a behavior that's especially hazardous should the JSON snippet under test be sufficiently large and/or complex to disallow our eyes catching the collapse.

Best regards,

David Newkirk

To reproduce paste a JSON on http://www.jsonlint.com/
click validate
results flash on screen and are removed upon reload
adding ';return false' to the onclick event makes it work

i have this issue using both firefox and chromium

It would be a nice feature to add URL Decode (or other popular decoding like base64) and validate after as separate function

Example:
//truncat
{
"x": 0.100
}
//error
{
"x": 001
}

Also observed in Pro.

pls if its possible, make option to auto fix Parse error of Expecting 'STRING', (Wrap key from double quotation mark).

All of the following are valid JSON.parses on all major browsers
see http://es5.github.io/x15.12.html#x15.12.1.2

JSON.parse(1)
JSON.parse("0")
JSON.parse(true)
JSON.parse("false")
JSON.parse(null)
JSON.parse("null")
JSON.parse("\"foo\"")

However all of these are listed as JSONLint errors because they are not wrapped by either [ or {, however this does not seem to be an actual part of the ES5 specification nor do browser native parsers have this requirement.

First of all thanks. This is an awesome jsonlinter. I'm using it a lot and love it!!

I can not search with the normal browser search (cmd+f ) in the pasted json. It seems that it is only searching in the user visible area but not in the whole json.

Im using a MacBook Pro (Retina, 13-inch, Early 2015) with macOS Sierra 10.12.4 (16E195) and Chrome Version 58.0.3029.110 (64-bit)

Steps to reproduce:

1. paste a json with more than 60 lines to jsonlint.com
2. search for a string with cmd+f that is not in the visible area of jsonlint's input field

e.g.

jsonlint.com?q={"test": 123}

And it will validate and format the json.

Thanks for the great service!

The tool passes the script into the URL?

http://localhost/jsonlint/?code=%5B%7B%22created_at%22%3A%22Wed+Jan+27+04%3A55%...

Submitted URI too large!

The length of the requested URL exceeds the capacity limit for this server. The request cannot be processed.

If you think this is a server error, please contact the webmaster.

Error 414

localhost
Apache/2.4.17 (Win32) OpenSSL/1.0.2d PHP/5.5.30

Hello,
How come "test" is a valid JSON ?
Other validators say it's invalid (as I thought)
Cheers

Favicon would need a background or something to look better in some browsers (ex: Chrome screenshot)

In the FAQ, an example link is provided for testing JSON linting via query string parameters. The link points to http://www.jsonlint.com/?json=%7B%22hello%22%3A%20%22world%22%7D. This returns status 404. However, http://jsonlint.com/?json=%7B%22hello%22%3A%20%22world%22%7D (without www prefix) works as expected.

Possible solution: nginx configuration for redirecting www to non-www here

Hi.

pro.jsonlint.com has a DNS error, it worked up until a day or two ago!

When I copy/cut the validated json in Firefox 48 / Windows 10, pasting it anywhere results in pasting a single -.

So even pressing Ctrl+X, Ctrl+V in succession will reduce any code in the code field to a single dash character. Always, valid or not.

Hello JSONLint - Team,

I found a small bug in your tool: if a json contents a carriage (not a carriage-return) your validator tells me, that everything is valid. IMO a valid JSON mustn't contain a carriage-character.

Best regards,
Anwey

Mac OSX. Pro version works

When I put a JSON document that contains quotation marks, it fails (like, for example '”'). If I replace those ones with the normal double quote (like this one '"'), it works perfectly.
Example:

{“status”: 200,”name”: 
 “Tanya Anderssen”,
  ”version”: {
     “number”: “1.3.4",
     ”build_hash”: “a70f3ccb52200f8f2c87e9c370c6597448eb3e45",
     ”build_timestamp”: “2014–09–30T09:07:17Z”,
     ”build_snapshot”: false,
     ”lucene_version”: “4.9"},
   ”tagline”: “You Know, for Search”
}

Thanks

The below:

{"foo":"foo\nbar"}

Validates in JSONLint

However, if I am reading http://json.org/ correctly, the above is not valid since it contains an unsescaped escape character:

"...any-Unicode-character-except-"-or--or-control-character
" \
/
\b
\f
\n
\r
\t
\u

Who is right here...?

Please add a simple clear button to clear the content of the validator so I can validate a new string again.

I may be missing something obvious, but this appears to show a mismatch in line numbers between what's highlighted above and what's written in the error message below:

Any thoughts?

The line numering is off in http://pro.jsonlint.com/

The problem might be browser related, because it only occurs in my Firefox 44.0.2
The same JSON looks fine in my Chrome 39.0.2

End of JSON in text editor:

End of JSON in Chrome

End of JSON in Firefox

It looks as if the lines are off by a few fractions of a pixel, but if the JSON is large it makes a big difference.

Why not give the textarea and the line div the same font, line height and font size? That would probably make sure the shown lines always match the actual line number.

This might be related to #18