I think we're in agreement, originally it was suggested to use a "null" string, instead of NULL as a value, which is what I said might cause weird error cases.

I think we're in agreement, originally it was suggested to use a "null" string, instead of NULL as a value, which is what I said might cause weird error cases. > So in the JSON itself, you literally remove the field. That's a good point, but in some cases having a `null` is an easier option, as you only need to determine if the value is valid, not if it exists AND is valid (but I suppose you could say it's always valid if it exists... that's if you trust the endpoint to provide valid values though). > But consider an example where you're loading some code into a VM's RAM Allocating memory locations from dynamically created JSON values is bound to lead to many different errors... I guess my main point is that JSON is inherently untyped and suited for messy data or user input. This messiness makes data validation on the consumer of the JSON necessary, which means the consumer has to check if the value is valid before using it. In most cases `null` is considered invalid but if the field isn't there, then it could be an error in the JSON provider.