Understanding the endianness of MIPS. Why is data being stored in little endian format but output looks big endian

This MIPS assembly program shown below is meant to count the number of characters in a string. This program was written using the MARS MIPS simulator (available from https://dpetersanderson.github.io/)

#---------------------------------------------
# Count the number of characters of a string.
#--------------------------------------------- 
.data 
inputStr: .asciiz "Help"

.text
la $t0, inputStr         # This now contains the address of the leading byte of inputStr
li $t2, 0                # This will contain the count of the characters.   

start_while_loop:
   lb   $t3, 0($t0)       # Load a byte from computed address into integer
   sne  $t1, $t3, '\0'    # Check if the character in $t3 is NUL 
   beqz $t1, end_for_loop # Goto the end of the loop if the character is indeed NUL

   #-------------------------------------------
   # Print the non-null character just loaded
   #------------------------------------------
   li   $v0, 11
   move $a0, $t3
   syscall

   addi $t2, $t2, 1       # Increment the count of the characters.       
   addi $t0, $t0, 1       # Increment the address, for the next iteration. 

   b start_while_loop
end_for_loop:

move $a0, $t2 
li   $v0, 1
syscall

# Exit the program
li $v0, 10
syscall

Here is a screenshot of my output window

The code counts the number of characters (4 in this case) as expected, I am having trouble understanding the behavior from the perspective of endianness. Specifically, I would have expected the output of the program to be pleH4 and not Help4 for the reasons given below.

When I execute the program, and I look into the Data Segment window of MARS I see this

As you can see Help is stored backward as pleH. This seemed weird since Hennessey Patterson say explicitly in their book "Computer Organization and Design" that the MIPS processor is in the Big Endian camp. Since each character is a byte and MIPS word is 4 bytes long, I would have expected the 4 characters to be stored inside a word as Help and not pleH. Hennessey and Patterson mention however, in the appendix when describing SPIM (their own MIPS simulator)

So ostensibly the same thing is happening on my machine that has an AMD Ryzen CPU and so Mars is using the CPU's little endianness.

BUT then when I try to print out the characters one byte at a time I get the letters Help in the "normal" order and not pleH.

What exactly is happening here? Where am I messing up in my understanding of endianness vis-a-vis MIPS?

Where am I messing up in my understanding of endianness vis-a-vis MIPS?

As far as I can tell you understand it perfectly and you're just being confused by the debugger display.

The MARS 4.5 Debugger documentation says

... All data are stored in little-endian byte order (each word consists of byte 3 followed by byte 2 then 1 then 0). Note that each word can hold 4 characters of a string and those 4 characters will appear in the reverse order from that of the string literal.

(my emphasis)

Endianness is (according to Wikipedia whose definition looks as good as any)

the order in which bytes within a word of digital data are transmitted ... or addressed (by rising addresses) in computer memory ...

Where "word" means some natural fixed-size datum larger than a byte, like for example a register (or practically including 16-bit halfwords on 32-bit or 64-bit systems, etc).

A character string is not such a datum, and endianness is not at all applicable.

Strings are variable length and stored with successive characters in consecutive increasing addresses. The characters are not typically packed into registers for integral computation (exceptions like vectorized string operations are an implementation detail, and the traditional layout of character strings is not affected).