--- JSON-XS/XS.pm	2013/05/23 09:31:32	1.139
+++ JSON-XS/XS.pm	2013/06/27 11:45:17	1.140
@@ -85,7 +85,7 @@
 =item * simple to use
 
 This module has both a simple functional interface as well as an object
-oriented interface interface.
+oriented interface.
 
 =item * reasonably versatile output formats
 
@@ -743,7 +743,7 @@
 exactly I<one> JSON object. If that is successful, it will return this
 object, otherwise it will return C<undef>. If there is a parse error,
 this method will croak just as C<decode> would do (one can then use
-C<incr_skip> to skip the errornous part). This is the most common way of
+C<incr_skip> to skip the erroneous part). This is the most common way of
 using the method.
 
 And finally, in list context, it will try to extract as many objects
@@ -782,7 +782,7 @@
 parse state.
 
 The difference to C<incr_reset> is that only text until the parse error
-occured is removed.
+occurred is removed.
 
 =item $json->incr_reset
 
@@ -990,7 +990,7 @@
 a numeric (floating point) value if that is possible without loss of
 precision. Otherwise it will preserve the number as a string value (in
 which case you lose roundtripping ability, as the JSON number will be
-re-encoded toa JSON string).
+re-encoded to a JSON string).
 
 Numbers containing a fractional or exponential part will always be
 represented as numeric (floating point) values, possibly at a loss of
@@ -1000,7 +1000,7 @@
 Note that precision is not accuracy - binary floating point values cannot
 represent most decimal fractions exactly, and when converting from and to
 floating point, JSON::XS only guarantees precision up to but not including
-the leats significant bit.
+the least significant bit.
 
 =item true, false
 
@@ -1140,7 +1140,7 @@
 When C<utf8> is disabled (the default), then C<encode>/C<decode> generate
 and expect Unicode strings, that is, characters with high ordinal Unicode
 values (> 255) will be encoded as such characters, and likewise such
-characters are decoded as-is, no canges to them will be done, except
+characters are decoded as-is, no changes to them will be done, except
 "(re-)interpreting" them as Unicode codepoints or Unicode characters,
 respectively (to Perl, these are the same thing in strings unless you do
 funny/weird/dumb stuff).
@@ -1266,7 +1266,7 @@
    $json =~ s/"__proto__"\s*:/"__proto__renamed":/g;
 
 This works because C<__proto__> is not valid outside of strings, so every
-occurence of C<"__proto__"\s*:> must be a string used as property name.
+occurrence of C<"__proto__"\s*:> must be a string used as property name.
 
 If you know of other incompatibilities, please let me know.
 
@@ -1454,7 +1454,7 @@
 system's setlocale function with C<LC_ALL>.
 
 This breaks both perl and modules such as JSON::XS, as stringification of
-numbers no longer works correcly (e.g. C<$x = 0.1; print "$x"+1> might
+numbers no longer works correctly (e.g. C<$x = 0.1; print "$x"+1> might
 print C<1>, and JSON::XS might output illegal JSON as JSON::XS relies on
 perl to stringify numbers).