Nextion Upload Protocol v1.2 (the fast one)


Have you ever wondered why the Nextion Editor can upload TFT files faster than any other tool? Simple. It uses a newer version of the Nextion Upload Protocol that allows to skip parts of the TFT file if they haven’t been modified. In practice this means that all of your pictures, fonts, etc (<= ressource section of the TFT file) will be skipped if you did not touch anyone of them. Only the stuff you coded/designed in the editor will be uploaded in that case.

As a lot of other useful information Nextion does not share any details about this improved protocol. However, it is not more complicated than the well-known protocol v1.1; the differences are minor. You should know and understand how that protocol works before continuing.

Ready-to-use Tool

I wrote a Python script called Nexus that implements this improved upload protocol. It can easily be used via command line. The script can be found here: Nexus - Nextion Upload Script

How it works

The faster protocol (let‘s call it v1.2) is essentially the same as v1.1 except for the following differences:

  • While v1.1 initiates the upload by sending the
    command, v1.2 uses
    whmi-wris FILE_SIZE,BAUD_RATE,1
    (there is an additional s!). The meaning of the third argument is not clear. It’s probably a “don’t care” as with v1.1. The Nextion editor seems to always set it to 1 and I had no problems with a 1 so far.
  • After sending the first block of 4096 bytes, which contains the file header, the screen will not return the usual 0x05 response but indicate at what address the download shall continue. The response begins with 0x08 followed by a 4-byte integer (little endian/lowest byte first). If that integer equals 0 the upload continues without skipping anything. Otherwise it continues at the specified offset.
    08 00 00 11 00 means f.ex. you shall continue at offset 0x110000. Note that the offset is relative to the beginning of the file, not the current position.
    I guess future devices could also return the 0x08 answer at other points during the upload so I wouldn’t hardcode it as an expected first block reply (see below).

Implementation and backward compatibility

  • v1.2 is only supported by devices that report a firmware version of 126 and higher (see connect command). For devices with older firmware (corresponding to editor v0.54 and earlier) you need to initiate the upload with the v1.1 command. Note: the v1.2 command won’t give you an error; apparently it was used for another, incompatible upload protocol in those firmware versions.
  • By not waiting explicitly for a 0x08 after the first block, the upload loop itself can be made compatible with both versions. Handle the return value conditionally. If Nextion returns 0x05 continue, else if Nextion returns 0x08 skip to the following offset, else throw an error. This is not only the easiest way to do it, but also the most flexible way. It can handle 0x08 replies at any point during the upload and doesn’t break compatibility with v1.1. That’s how I did it in my script linked above.


  • The 0x08 response takes longer than 0.5s on my device. More like ~1s. Therefore I set the serial timeout to 2s.
  • For some reason the first command after the connect procedure never works (for me at least). Doesn’t matter if I send a FF FF FF first or not, whatever is the next command it will fail (returns 1A FF FF FF). My solution is to send a dummy command and then continue normally.
  • The TFT file size is actually included in the TFT file at offset 0x3c-0x3f (little endian/lowest byte first). Could be easier/faster to read than to get the file size with other methods.

Happy uploading!


Hello Max,

thank you so much for your informations.

Did you every had a look into the checksum calculation?
I would be very interested in changing one part of the TFT (lets say, picture 0) and upload it.
I found the location of the picture, thats easy, i just used to filled colors for that picture and compared the files after building it, but the upload fails if i just change the block with the picture informations.
And i was not able to find out how the checksum is calculated. There is some small change at the begin of the file and at the end.


Hi @Alex-2.5,

Yes, I do have more knowledge about the TFT files including how to modify some parts of them. This thread however is the wrong place for that kind of discussions. Please join us on discord.

Edit 13.05.21: By now these infos aren‘t secret anymore: TFT Reverse Engineering and more

Kind regards,

First major update!

I wrote an easy-to-use script called Nexus that implements the new protocol. While working on this I found out that the protocol is even simpler than I thought originally (hence some unnecessary information has been removed from the first post while the new knowledge is now included). It has been successfully tested and scans the ports faster than the Nextion Editor.

Kind regards,


The post at the top and the Nexus tool both have been updated with backward compatibility for devices that don’t support upload protocol v1.2.
Spoiler: it’s not hard at all.

Kind regards,


To add some information:

  • the reported firmware version depends on the device. E.g. my 3,5" F-model is reporting version 48 and supports ‘v1.2’.
  • looking at the communication, the negative response is created by the escape sequence for protocol reparse mode ‘DRAKJHSUYDGBNCJHGJKSHBDN\xff\xff\xff’ already and thus not related to the ‘next command’. I did not check which answer would be send in case the display is in protocol reparse mode.
  • as 2 connects are sent also 2 answers are created. Maybe because of a bug in the bootloader the second answer is sent as a reply to the following (write/dummy) command.
  • instead of sending the full “escape/connect sequence” I wait for the answer of each command and know how to react on each response.
  • to receive the 4 byte integer after 0x08 can take some time. For my display and the used configuration it took ~1s.