The examples you provided (with some context gleaned from your other comments) look like they're probably too long and tack on unnecessary domain specific detail (e.g. jsonStates).
Both variables in your example would likely be better off describing the use of the variable rather than the contents. E.g. use ageInYears rather than yearsAliveInt. Taking it to your example, perhaps something along the lines of convertedDocument would do, this is significantly shorter than your example, but perhaps conveys enough info for your ongoing usage.
This is covered to in Clean Code [1]. "The name of a variable, function, or class, should answer all the big questions. It should tell you why it exists, what it does, and how it is used." The notes on the naming chapter at [2] are quite good as well (as noted elsewhere on this thread by @runesoerensen)
I like to follow the principle in naming variables that if I could read the code to a non-technical user verbatim and have them understand the code, it is "good code". I.e. does reading the code out loud as a sentence make sense, or do the verbs and nouns I've chosen act as a barrier to understanding.
EDIT:
Ward Cunningham said that last part better: “You know you are working on clean code when each routine you read turns out to be pretty much what you expected. You can call it beautiful code when the code also makes it look like the language was made for the problem.”
[1] Martin, Robert C. (2008-08-01). Clean Code: A Handbook of Agile Software Craftsmanship (p. 18). Pearson Education. Kindle Edition. https://www.amazon.com/Clean-Code-Handbook-Software-Craftsma...