Minor typo: 'likley' to 'likely' (#975)

1 files changed, 1 insertions, 1 deletions

diff --git a/TextFormat.md b/TextFormat.md
index 9276d0c..5bb87c0 100644
--- a/TextFormat.md
+++ b/TextFormat.md
@@ -124,6 +124,6 @@ cases:
 
 There is no requirement to use JavaScript syntax; this format is not intended to be evaluated or translated directly into JavaScript. There may also be substantive reasons to use notation that is different than JavaScript (for example, WebAssembly has a 64-bit integer type, and it should be represented in the text format, since that is the natural thing to do for WebAssembly, regardless of JavaScript not having such a type). On the other hand, when there are no substantive reasons and the options are basically bikeshedding, then it does make sense for the text format to match existing conventions on the Web (for example, curly braces, as in JavaScript and CSS).
 
-The text format may not be uniquely representable. Multiple textual files will likley assemble to the same binary file. For example, whitespace shouldn't be significant and memory initialization can be broken out into smaller pieces in a text format.
+The text format may not be uniquely representable. Multiple textual files will likely assemble to the same binary file. For example, whitespace shouldn't be significant and memory initialization can be broken out into smaller pieces in a text format.
 
 The text format should be precise in that values that cannot be accurately represented in the binary format are considered invalid text. Floating-point numbers should therefore be represented as hexadecimal floating-point as specified by C99, C++17, and IEEE-754-2008 section 5.12.3. The textual format may be improved to also support more human-readable representations, but never at the cost of accurate representation.